From dale at daleenterprise.com  Tue Feb  1 06:23:09 2011
From: dale at daleenterprise.com (Dale Walsh)
Date: Tue, 1 Feb 2011 06:23:09 -0500
Subject: unable to write flashrom, functionality broken?
Message-ID: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>

I had a hard drive failure which forced me to perform a fresh/clean  
installation of ubuntu 10 on a new drive since the old drive no  
longer functions (it was rather old).

My use of the b43 software is only for modification of the PCI ID's  
of the flashrom and the original installation was provided to me on  
the HD.

Now I am unable to write the flashrom after the new installation it  
always reports "write error: Operation Not Supported" and this is  
using the same cards I was flashing before, I even tried using a  
previously modified card and I get the same failure.

Since it worked before I can only conclude that the new software is  
broken and the ability to write is a requirement, can someone help me  
resolve this please.

-- Dale



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110201/90d5750c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110201/90d5750c/attachment.sig>

From zajec5 at gmail.com  Tue Feb  1 07:51:01 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Tue, 1 Feb 2011 13:51:01 +0100
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
Message-ID: <AANLkTikoBMgObBgM7tz8sPPKRdKV0fky-BAoe_K_LgPj@mail.gmail.com>

2011/2/1 Dale Walsh <dale at daleenterprise.com>:
> I had a hard drive failure which forced me to perform a fresh/clean
> installation of ubuntu 10 on a new drive since the old drive no longer
> functions (it was rather old).
> My use of the b43 software is only for modification of the PCI ID's of the
> flashrom and the original installation was provided to me on the HD.
> Now I am unable to write the flashrom after the new installation it always
> reports "write error: Operation Not Supported" and this is using the same
> cards I was flashing before, I even tried using a?previously?modified card
> and I get the same failure.
> Since it worked before I can only conclude that the new software is broken
> and the ability to write is a requirement, can someone help me resolve this
> please.

Do you mean ssb driver functionality? I remember Michael was fixing
writing some time ago:

commit e33761e6f23881de9f3ee77cc2204ab2e26f3d9a
Author: Michael Buesch <mb at bu3sch.de>
Date:   Mon Nov 23 20:58:06 2009 +0100

    ssb: Fix range check in sprom write

    The range check in the sprom image parser hex2sprom() is broken.
    One sprom word is 4 hex characters.
    This fixes the check and also adds much better sanity checks to the code.
    We better make sure the image is OK by doing some sanity checks to avoid
    bricking the device by accident.

    Signed-off-by: Michael Buesch <mb at bu3sch.de>
    Cc: stable at kernel.org
    Signed-off-by: John W. Linville <linville at tuxdriver.com>

commit 3ba6018aa314559c5867138a8173b068268a70db
Author: Michael Buesch <mb at bu3sch.de>
Date:   Mon Nov 23 20:12:13 2009 +0100

    ssb: Fix SPROM writing

    The SPROM writing routines were broken since we rewrote the suspend
    handling on wireless devices, because SPROM writing depended on suspend.

    This patch changes it and freezes devices with the driver remove(), probe()
    callbacks instead. This also simplifies the whole logics a lot.

    Signed-off-by: Michael Buesch <mb at bu3sch.de>
    Signed-off-by: John W. Linville <linville at tuxdriver.com>

Do you have that patches in your kernel?

-- 
Rafa?


From gavron at wetwork.net  Tue Feb  1 07:57:16 2011
From: gavron at wetwork.net (Ehud Gavron)
Date: Tue, 01 Feb 2011 05:57:16 -0700
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
Message-ID: <4D48032C.4070107@wetwork.net>

On 02/01/2011 04:23 AM, Dale Walsh wrote:
> I had a hard drive failure which forced me to perform a fresh/clean installation of ubuntu 10 on a new drive since the old drive 
> no longer functions (it was rather old).
>
> My use of the b43 software is only for modification of the PCI ID's of the flashrom and the original installation was provided to 
> me on the HD.
>
> Now I am unable to write the flashrom after the new installation it always reports "write error: Operation Not Supported" and this 
> is using the same cards I was flashing before, I even tried using a previously modified card and I get the same failure.
>
> Since it worked before I can only conclude that the new software is broken and the ability to write is a requirement, can someone 
> help me resolve this please.
>
> -- Dale
>
>
Rafal covered some commits but I'm confused why you don't restore your backup and see why that works and your current system doesn't.

Best regards,

Ehud Gavron
Tucson AZ US SOL3

>
>
> _______________________________________________
> b43-dev mailing list
> b43-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/b43-dev

-- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110201/e09c6b66/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ehudwetworkcontactqrcode.png
Type: image/png
Size: 1007 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110201/e09c6b66/attachment.png>

From d.cristiani at idem-tech.it  Tue Feb  1 09:41:35 2011
From: d.cristiani at idem-tech.it (dylan cristiani)
Date: Tue, 1 Feb 2011 15:41:35 +0100
Subject: Trouble using bcm4318 compact flash with b43 driver
In-Reply-To: <20110122114834.00007abc@unknown>
References: <20110114182113.0000753f@unknown> <4D309B73.8050402@lwfinger.net>
	<20110115080500.00001c48@unknown> <4D31CDA3.9040304@lwfinger.net>
	<20110117110618.0000170f@unknown> <20110117145106.00001ec8@unknown>
	<20110118115855.00007877@unknown> <4D35A506.3090702@lwfinger.net>
	<20110119140328.00002dd2@unknown> <20110121165137.000016ff@unknown>
	<4D39C0B9.8050708@lwfinger.net> <20110121225408.00003e2c@unknown>
	<4D3A050D.3090106@lwfinger.net> <20110122114834.00007abc@unknown>
Message-ID: <20110201154135.00006f0b@unknown>

On Sat, 22 Jan 2011 11:48:34 +0100
Dylan Cristiani <d.cristiani at idem-tech.it> wrote:

[snip]
> > 
> > If you don't have any version that always works, then bisection is
> > likely not the answer. You will need to investigate what is on the
> > air by using kismet or wireshark on a separate computer.
> i'll try with kismet or wireshark (keeping my finger crossed....,but
> the fact that problems are intermittent make me feel bad....)
> > 
> > Larry
> tks again Larry!!
> 
i have some news: i went back to kernel version 2.6.26 and it worked
so i moved forward kernel by kernel and it works till kernel 2.6.32;
first kernel that shows up the problem is 2.6.33 and, at module loading
time i can see for the first time, after loading firmware, the following
debug info (don't know if it's helpful but same message happears in
every non-working kernel from 2.6.33 to 2.6.37):

"b43-phy0 warning: Invalid max-TX-power value in SPROM"

dylan


From Larry.Finger at lwfinger.net  Tue Feb  1 11:28:48 2011
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Tue, 01 Feb 2011 10:28:48 -0600
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
Message-ID: <4D4834C0.5060701@lwfinger.net>

On 02/01/2011 05:23 AM, Dale Walsh wrote:
> I had a hard drive failure which forced me to perform a fresh/clean
> installation of ubuntu 10 on a new drive since the old drive no longer
> functions (it was rather old).
> 
> My use of the b43 software is only for modification of the PCI ID's of
> the flashrom and the original installation was provided to me on the HD.
> 
> Now I am unable to write the flashrom after the new installation it
> always reports "write error: Operation Not Supported" and this is using
> the same cards I was flashing before, I even tried using
> a previously modified card and I get the same failure.
> 
> Since it worked before I can only conclude that the new software is
> broken and the ability to write is a requirement, can someone help me
> resolve this please.

I do not doubt that the SPROM writing function is broken, but I wonder why you
are needing it now. Why was it necessary to rewrite the SPROM in the first
place? Once that was done, then it should never need to be done again. Please
explain what you did and what you are doing now.

Larry


From Larry.Finger at lwfinger.net  Tue Feb  1 15:40:32 2011
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Tue, 01 Feb 2011 14:40:32 -0600
Subject: Trouble using bcm4318 compact flash with b43 driver
In-Reply-To: <20110201154135.00006f0b@unknown>
References: <20110114182113.0000753f@unknown>	<4D309B73.8050402@lwfinger.net>	<20110115080500.00001c48@unknown>	<4D31CDA3.9040304@lwfinger.net>	<20110117110618.0000170f@unknown>	<20110117145106.00001ec8@unknown>	<20110118115855.00007877@unknown>	<4D35A506.3090702@lwfinger.net>	<20110119140328.00002dd2@unknown>	<20110121165137.000016ff@unknown>	<4D39C0B9.8050708@lwfinger.net>	<20110121225408.00003e2c@unknown>	<4D3A050D.3090106@lwfinger.net>	<20110122114834.00007abc@unknown>
	<20110201154135.00006f0b@unknown>
Message-ID: <4D486FC0.3020507@lwfinger.net>

On 02/01/2011 08:41 AM, dylan cristiani wrote:
> i have some news: i went back to kernel version 2.6.26 and it worked
> so i moved forward kernel by kernel and it works till kernel 2.6.32;
> first kernel that shows up the problem is 2.6.33 and, at module loading
> time i can see for the first time, after loading firmware, the following
> debug info (don't know if it's helpful but same message happears in
> every non-working kernel from 2.6.33 to 2.6.37):
> 
> "b43-phy0 warning: Invalid max-TX-power value in SPROM"

Between 2.6.32 and 2.6.33, there were only 6 patches that touched SSB. Two of
them (e33761e and 3ba6018) affected SPROM writing, one (37ace3d) was only for
PCMCIA, and one (ac2752c) only affected logging of a core scan. The two
remaining are 391ae22 that fixed an SDIO typo and 8b45499 that put host pointers
in a union should be the only ones that needed testing.

Those patches are attached. Try each of them in turn to 2.6.33 with a
'patch -p1 -R < patch_name' If it doesn't help, use the same command without the
"-R" to reapply. I'm guessing that 8b45499 is more likely to be the problem, and
I would try it first.

Larry
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_391ae22
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110201/340c8ec1/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_8b45499
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110201/340c8ec1/attachment-0001.ksh>

From dale at daleenterprise.com  Wed Feb  2 02:50:44 2011
From: dale at daleenterprise.com (Dale Walsh)
Date: Wed, 2 Feb 2011 02:50:44 -0500
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <4D4834C0.5060701@lwfinger.net>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
Message-ID: <463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>

On Feb 01, 2011, at 11:28 AM, Larry Finger wrote:

> On 02/01/2011 05:23 AM, Dale Walsh wrote:
>> I had a hard drive failure which forced me to perform a fresh/clean
>> installation of ubuntu 10 on a new drive since the old drive no  
>> longer
>> functions (it was rather old).
>>
>> My use of the b43 software is only for modification of the PCI  
>> ID's of
>> the flashrom and the original installation was provided to me on  
>> the HD.
>>
>> Now I am unable to write the flashrom after the new installation it
>> always reports "write error: Operation Not Supported" and this is  
>> using
>> the same cards I was flashing before, I even tried using
>> a previously modified card and I get the same failure.
>>
>> Since it worked before I can only conclude that the new software is
>> broken and the ability to write is a requirement, can someone help me
>> resolve this please.
>
> I do not doubt that the SPROM writing function is broken, but I  
> wonder why you
> are needing it now. Why was it necessary to rewrite the SPROM in  
> the first
> place? Once that was done, then it should never need to be done  
> again. Please
> explain what you did and what you are doing now.

Since not all cards are created equal I take a card with specific  
features and functionality, change the ID's to my own for use with my  
own custom drivers which provides added functionality for cards with  
my ID's.

If the cards do not have my ID's they have the basic functionality  
that people are used to seeing, with my ID's they have the ability to  
run in simultaneous dual band mode (2.4ghz and 5ghz adhoc) and I use  
these ID's to ensure that the drivers only work on cards I approve.

My only need for linux is to rebrand the cards with my ID's.

If I understood enough about the write mechanism I would forego the  
b43 code all together and create an app that reads and writes the  
flashrom but the time involved  in sifting through the ubuntu code  
due to it's source structure makes it a daunting task that turns me off.


As before when working in the original installation (provided to me  
as a working installation) I would do the following: (both cat and cp  
fail)


sudo su; # become root to avoid permission issues

cd /PATH TO DIR OF ssb_sprom; # I verify ssb_sprom exists in this  
location

rmmod b43; # unload the driver

cat updated_sprom >ssb_sprom; # write the updated file


This results in write failure under the new installation.


cp updated_sprom >ssb_sprom


This also results in a write failure under the new installation.

>
> Larry
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110202/03c4f448/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110202/03c4f448/attachment.sig>

From d.cristiani at idem-tech.it  Wed Feb  2 04:11:51 2011
From: d.cristiani at idem-tech.it (dylan cristiani)
Date: Wed, 2 Feb 2011 10:11:51 +0100
Subject: Trouble using bcm4318 compact flash with b43 driver
In-Reply-To: <4D486FC0.3020507@lwfinger.net>
References: <20110114182113.0000753f@unknown> <4D309B73.8050402@lwfinger.net>
	<20110115080500.00001c48@unknown> <4D31CDA3.9040304@lwfinger.net>
	<20110117110618.0000170f@unknown> <20110117145106.00001ec8@unknown>
	<20110118115855.00007877@unknown> <4D35A506.3090702@lwfinger.net>
	<20110119140328.00002dd2@unknown> <20110121165137.000016ff@unknown>
	<4D39C0B9.8050708@lwfinger.net> <20110121225408.00003e2c@unknown>
	<4D3A050D.3090106@lwfinger.net> <20110122114834.00007abc@unknown>
	<20110201154135.00006f0b@unknown> <4D486FC0.3020507@lwfinger.net>
Message-ID: <20110202101151.00007105@unknown>

On Tue, 01 Feb 2011 14:40:32 -0600
Larry Finger <Larry.Finger at lwfinger.net> wrote:

> On 02/01/2011 08:41 AM, dylan cristiani wrote:
> > i have some news: i went back to kernel version 2.6.26 and it worked
> > so i moved forward kernel by kernel and it works till kernel 2.6.32;
> > first kernel that shows up the problem is 2.6.33 and, at module
> > loading time i can see for the first time, after loading firmware,
> > the following debug info (don't know if it's helpful but same
> > message happears in every non-working kernel from 2.6.33 to 2.6.37):
> > 
> > "b43-phy0 warning: Invalid max-TX-power value in SPROM"
> 
> Between 2.6.32 and 2.6.33, there were only 6 patches that touched
> SSB. Two of them (e33761e and 3ba6018) affected SPROM writing, one
> (37ace3d) was only for PCMCIA, and one (ac2752c) only affected
> logging of a core scan. The two remaining are 391ae22 that fixed an
> SDIO typo and 8b45499 that put host pointers in a union should be the
> only ones that needed testing.
> 
> Those patches are attached. Try each of them in turn to 2.6.33 with a
> 'patch -p1 -R < patch_name' If it doesn't help, use the same command
> without the "-R" to reapply. I'm guessing that 8b45499 is more likely
> to be the problem, and I would try it first.
> 
> Larry
Hi Larry i tryied to reverte two patches you sent me but nothing
happens; but i discovered interesting behaviour: the mac address of the
module is:
00:0B:B6....
but starting from 2.6.33 the chip is read as:
14:0B:B6....
(maybe the '0x14' value could be '20dBm' related to the max-TX-power
value.....); so it seems that the driver is faulty reading the chip
properties from sprom (in fact till the 2.6.32 the mac address was
correct and the max-TX-power warning wasn't issued); i noticed that
into drivers/ssb/pcmcia.c tha way to read properties from the chip is
changed also; hope this helps

thanks

dylan


From d.cristiani at idem-tech.it  Wed Feb  2 06:55:29 2011
From: d.cristiani at idem-tech.it (dylan cristiani)
Date: Wed, 2 Feb 2011 12:55:29 +0100
Subject: Trouble using bcm4318 compact flash with b43 driver
In-Reply-To: <20110202101151.00007105@unknown>
References: <20110114182113.0000753f@unknown> <4D309B73.8050402@lwfinger.net>
	<20110115080500.00001c48@unknown> <4D31CDA3.9040304@lwfinger.net>
	<20110117110618.0000170f@unknown> <20110117145106.00001ec8@unknown>
	<20110118115855.00007877@unknown> <4D35A506.3090702@lwfinger.net>
	<20110119140328.00002dd2@unknown> <20110121165137.000016ff@unknown>
	<4D39C0B9.8050708@lwfinger.net> <20110121225408.00003e2c@unknown>
	<4D3A050D.3090106@lwfinger.net> <20110122114834.00007abc@unknown>
	<20110201154135.00006f0b@unknown> <4D486FC0.3020507@lwfinger.net>
	<20110202101151.00007105@unknown>
Message-ID: <20110202125529.00002e75@unknown>

On Wed, 2 Feb 2011 10:11:51 +0100
dylan cristiani <d.cristiani at idem-tech.it> wrote:

> On Tue, 01 Feb 2011 14:40:32 -0600
> Larry Finger <Larry.Finger at lwfinger.net> wrote:
> 
> > On 02/01/2011 08:41 AM, dylan cristiani wrote:
> > > i have some news: i went back to kernel version 2.6.26 and it
> > > worked so i moved forward kernel by kernel and it works till
> > > kernel 2.6.32; first kernel that shows up the problem is 2.6.33
> > > and, at module loading time i can see for the first time, after
> > > loading firmware, the following debug info (don't know if it's
> > > helpful but same message happears in every non-working kernel
> > > from 2.6.33 to 2.6.37):
> > > 
> > > "b43-phy0 warning: Invalid max-TX-power value in SPROM"
> > 
> > Between 2.6.32 and 2.6.33, there were only 6 patches that touched
> > SSB. Two of them (e33761e and 3ba6018) affected SPROM writing, one
> > (37ace3d) was only for PCMCIA, and one (ac2752c) only affected
> > logging of a core scan. The two remaining are 391ae22 that fixed an
> > SDIO typo and 8b45499 that put host pointers in a union should be
> > the only ones that needed testing.
> > 
> > Those patches are attached. Try each of them in turn to 2.6.33 with
> > a 'patch -p1 -R < patch_name' If it doesn't help, use the same
> > command without the "-R" to reapply. I'm guessing that 8b45499 is
> > more likely to be the problem, and I would try it first.
> > 
> > Larry
> Hi Larry i tryied to reverte two patches you sent me but nothing
> happens; but i discovered interesting behaviour: the mac address of
> the module is:
> 00:0B:B6....
> but starting from 2.6.33 the chip is read as:
> 14:0B:B6....
> (maybe the '0x14' value could be '20dBm' related to the max-TX-power
> value.....); so it seems that the driver is faulty reading the chip
> properties from sprom (in fact till the 2.6.32 the mac address was
> correct and the max-TX-power warning wasn't issued); i noticed that
> into drivers/ssb/pcmcia.c tha way to read properties from the chip is
> changed also; hope this helps
Hi larry i located the problem: at ssb level the info (MAC,
max-TX-power and friends) are ok, while when at b43 driver level there
are some data corruption; here comes the log of some debug i put into
drivers followed by the code slices where i put the debug; i'm sure
i'll find the trouble:

boot log
...
MMMMAC0 = 0
MMMMAC1 = b
MMMMAC1 = 6b
MMMMAC1 = 1e
MMMMAC1 = 3e
MMMMAC1 = 86

sprom->maxpwr_bg = 76

ssb: Sonics Silicon Backplane found on PCMCIA device pcmcia0.0

IEEEMMMMAC0 = 14
IEEEMMMMAC1 = b
IEEEMMMMAC1 = 6b
IEEEMMMMAC1 = 1e
IEEEMMMMAC1 = 3e
IEEEMMMMAC1 = 86

b43-phy0: Broadcom 4318 WLAN found (core revision 9)
Broadcom 43xx driver loaded [ Features: M, Firmware-ID: FW13 ]
Reconfiguring network interfaces... 
ip: RTNETLINK answers: File exists 
b43 ssb0:0: firmware: requesting b43/ucode5.fw
buf=31 a 0loading=1buf=30 a 0loading=0
b43 ssb0:0: firmware: requesting b43/pcm5.fw
buf=31 a 0loading=1buf=30 a 0loading=0
b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
buf=31 a 0loading=1buf=30 a 0loading=0
b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
buf=31 a 0loading=1buf=30 a 0loading=0
b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)

phy_g max_pwr_bg = 65535

b43-phy0 warning: Invalid max-TX-power value in SPROM.
udhcpc (v1.17.4) started
Sending discover...
phy_g max_pwr_bg = 80
Sending discover...
Sending discover...
No lease, failing
.....

and here the sources:

drivers/ssb/pcmcia.c

static int ssb_pcmcia_get_mac(struct pcmcia_device *p_dev,
			tuple_t *tuple,
			void *priv)
{
	struct ssb_sprom *sprom = priv;

	if (tuple->TupleData[0] != CISTPL_FUNCE_LAN_NODE_ID)
		return -EINVAL;
	if (tuple->TupleDataLen != ETH_ALEN + 2)
		return -EINVAL;
	if (tuple->TupleData[1] != ETH_ALEN)
		return -EINVAL;
	memcpy(sprom->il0mac, &tuple->TupleData[2], ETH_ALEN);

//ssb_log
	printk(KERN_INFO "MMMMAC0 = %x", sprom->il0mac[0]);
	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[1]);
	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[2]);
	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[3]);
	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[4]);
	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[5]);
//ssb_log

	return 0;
};
.....

static int ssb_pcmcia_do_get_invariants(struct pcmcia_device *p_dev,
					tuple_t *tuple,
					void *priv)
{
.....

		sprom->maxpwr_bg = tuple->TupleData[8];
//ssb_log
		printk(KERN_INFO "sprom->maxpwr_bg = %d",
		sprom->maxpwr_bg); 
//ssb_log

......


drivers/net/wireless/b43/main.c

static int b43_wireless_init(struct ssb_device *dev)
{
....

	if (is_valid_ether_addr(sprom->et1mac))
		SET_IEEE80211_PERM_ADDR(hw, sprom->et1mac);
	else
		SET_IEEE80211_PERM_ADDR(hw, sprom->il0mac);

//b43_main_log
	printk(KERN_INFO "IEEEMMMMAC0 = %x", sprom->il0mac[0]);
	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[1]);
	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[2]);
	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[3]);
	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[4]);
	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[5]);
//b43_main_log

....

drivers/net/wireless/b43/phy_g.c


	/* Estimate the TX power emission based on the TSSI */
	estimated_pwr = b43_gphy_estimate_power_out(dev, average_tssi);

	B43_WARN_ON(phy->type != B43_PHYTYPE_G);
	max_pwr = dev->dev->bus->sprom.maxpwr_bg;

//b43_phyg_log
	printk(KERN_INFO "phy_g max_pwr_bg = %d\n", max_pwr);
//b43_phyg_log

	if (dev->dev->bus->sprom.boardflags_lo & B43_BFL_PACTRL)
		max_pwr -= 3; /* minus 0.75 */

	if (unlikely(max_pwr >= INT_TO_Q52(30/*dBm*/))) {
		b43warn(dev->wl,
			"Invalid max-TX-power value in SPROM.\n");
		max_pwr = INT_TO_Q52(20); /* fake it */
		dev->dev->bus->sprom.maxpwr_bg = max_pwr;
	}
....


From d.cristiani at idem-tech.it  Wed Feb  2 10:30:02 2011
From: d.cristiani at idem-tech.it (dylan cristiani)
Date: Wed, 2 Feb 2011 16:30:02 +0100
Subject: Trouble using bcm4318 compact flash with b43 driver
In-Reply-To: <20110202125529.00002e75@unknown>
References: <20110114182113.0000753f@unknown> <4D309B73.8050402@lwfinger.net>
	<20110115080500.00001c48@unknown> <4D31CDA3.9040304@lwfinger.net>
	<20110117110618.0000170f@unknown> <20110117145106.00001ec8@unknown>
	<20110118115855.00007877@unknown> <4D35A506.3090702@lwfinger.net>
	<20110119140328.00002dd2@unknown> <20110121165137.000016ff@unknown>
	<4D39C0B9.8050708@lwfinger.net> <20110121225408.00003e2c@unknown>
	<4D3A050D.3090106@lwfinger.net> <20110122114834.00007abc@unknown>
	<20110201154135.00006f0b@unknown> <4D486FC0.3020507@lwfinger.net>
	<20110202101151.00007105@unknown> <20110202125529.00002e75@unknown>
Message-ID: <20110202163002.00005927@unknown>

On Wed, 2 Feb 2011 12:55:29 +0100
dylan cristiani <d.cristiani at idem-tech.it> wrote:

> On Wed, 2 Feb 2011 10:11:51 +0100
> dylan cristiani <d.cristiani at idem-tech.it> wrote:
> 
> > On Tue, 01 Feb 2011 14:40:32 -0600
> > Larry Finger <Larry.Finger at lwfinger.net> wrote:
> > 
> > > On 02/01/2011 08:41 AM, dylan cristiani wrote:
> > > > i have some news: i went back to kernel version 2.6.26 and it
> > > > worked so i moved forward kernel by kernel and it works till
> > > > kernel 2.6.32; first kernel that shows up the problem is 2.6.33
> > > > and, at module loading time i can see for the first time, after
> > > > loading firmware, the following debug info (don't know if it's
> > > > helpful but same message happears in every non-working kernel
> > > > from 2.6.33 to 2.6.37):
> > > > 
> > > > "b43-phy0 warning: Invalid max-TX-power value in SPROM"
> > > 
> > > Between 2.6.32 and 2.6.33, there were only 6 patches that touched
> > > SSB. Two of them (e33761e and 3ba6018) affected SPROM writing, one
> > > (37ace3d) was only for PCMCIA, and one (ac2752c) only affected
> > > logging of a core scan. The two remaining are 391ae22 that fixed
> > > an SDIO typo and 8b45499 that put host pointers in a union should
> > > be the only ones that needed testing.
> > > 
> > > Those patches are attached. Try each of them in turn to 2.6.33
> > > with a 'patch -p1 -R < patch_name' If it doesn't help, use the
> > > same command without the "-R" to reapply. I'm guessing that
> > > 8b45499 is more likely to be the problem, and I would try it
> > > first.
> > > 
> > > Larry
> > Hi Larry i tryied to reverte two patches you sent me but nothing
> > happens; but i discovered interesting behaviour: the mac address of
> > the module is:
> > 00:0B:B6....
> > but starting from 2.6.33 the chip is read as:
> > 14:0B:B6....
> > (maybe the '0x14' value could be '20dBm' related to the max-TX-power
> > value.....); so it seems that the driver is faulty reading the chip
> > properties from sprom (in fact till the 2.6.32 the mac address was
> > correct and the max-TX-power warning wasn't issued); i noticed that
> > into drivers/ssb/pcmcia.c tha way to read properties from the chip
> > is changed also; hope this helps
> Hi larry i located the problem: at ssb level the info (MAC,
> max-TX-power and friends) are ok, while when at b43 driver level there
> are some data corruption; here comes the log of some debug i put into
> drivers followed by the code slices where i put the debug; i'm sure
> i'll find the trouble:
> 
> boot log
> ...
> MMMMAC0 = 0
> MMMMAC1 = b
> MMMMAC1 = 6b
> MMMMAC1 = 1e
> MMMMAC1 = 3e
> MMMMAC1 = 86
> 
> sprom->maxpwr_bg = 76
> 
> ssb: Sonics Silicon Backplane found on PCMCIA device pcmcia0.0
> 
> IEEEMMMMAC0 = 14
> IEEEMMMMAC1 = b
> IEEEMMMMAC1 = 6b
> IEEEMMMMAC1 = 1e
> IEEEMMMMAC1 = 3e
> IEEEMMMMAC1 = 86
> 
> b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> Broadcom 43xx driver loaded [ Features: M, Firmware-ID: FW13 ]
> Reconfiguring network interfaces... 
> ip: RTNETLINK answers: File exists 
> b43 ssb0:0: firmware: requesting b43/ucode5.fw
> buf=31 a 0loading=1buf=30 a 0loading=0
> b43 ssb0:0: firmware: requesting b43/pcm5.fw
> buf=31 a 0loading=1buf=30 a 0loading=0
> b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
> buf=31 a 0loading=1buf=30 a 0loading=0
> b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
> buf=31 a 0loading=1buf=30 a 0loading=0
> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> 
> phy_g max_pwr_bg = 65535
> 
> b43-phy0 warning: Invalid max-TX-power value in SPROM.
> udhcpc (v1.17.4) started
> Sending discover...
> phy_g max_pwr_bg = 80
> Sending discover...
> Sending discover...
> No lease, failing
> .....
> 
> and here the sources:
> 
> drivers/ssb/pcmcia.c
> 
> static int ssb_pcmcia_get_mac(struct pcmcia_device *p_dev,
> 			tuple_t *tuple,
> 			void *priv)
> {
> 	struct ssb_sprom *sprom = priv;
> 
> 	if (tuple->TupleData[0] != CISTPL_FUNCE_LAN_NODE_ID)
> 		return -EINVAL;
> 	if (tuple->TupleDataLen != ETH_ALEN + 2)
> 		return -EINVAL;
> 	if (tuple->TupleData[1] != ETH_ALEN)
> 		return -EINVAL;
> 	memcpy(sprom->il0mac, &tuple->TupleData[2], ETH_ALEN);
> 
> //ssb_log
> 	printk(KERN_INFO "MMMMAC0 = %x", sprom->il0mac[0]);
> 	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[1]);
> 	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[2]);
> 	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[3]);
> 	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[4]);
> 	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[5]);
> //ssb_log
> 
> 	return 0;
> };
> .....
> 
> static int ssb_pcmcia_do_get_invariants(struct pcmcia_device *p_dev,
> 					tuple_t *tuple,
> 					void *priv)
> {
> .....
> 
> 		sprom->maxpwr_bg = tuple->TupleData[8];
> //ssb_log
> 		printk(KERN_INFO "sprom->maxpwr_bg = %d",
> 		sprom->maxpwr_bg); 
> //ssb_log
> 
> ......
> 
> 
> drivers/net/wireless/b43/main.c
> 
> static int b43_wireless_init(struct ssb_device *dev)
> {
> ....
> 
> 	if (is_valid_ether_addr(sprom->et1mac))
> 		SET_IEEE80211_PERM_ADDR(hw, sprom->et1mac);
> 	else
> 		SET_IEEE80211_PERM_ADDR(hw, sprom->il0mac);
> 
> //b43_main_log
> 	printk(KERN_INFO "IEEEMMMMAC0 = %x", sprom->il0mac[0]);
> 	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[1]);
> 	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[2]);
> 	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[3]);
> 	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[4]);
> 	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[5]);
> //b43_main_log
> 
> ....
> 
> drivers/net/wireless/b43/phy_g.c
> 
> 
> 	/* Estimate the TX power emission based on the TSSI */
> 	estimated_pwr = b43_gphy_estimate_power_out(dev,
> average_tssi);
> 
> 	B43_WARN_ON(phy->type != B43_PHYTYPE_G);
> 	max_pwr = dev->dev->bus->sprom.maxpwr_bg;
> 
> //b43_phyg_log
> 	printk(KERN_INFO "phy_g max_pwr_bg = %d\n", max_pwr);
> //b43_phyg_log
> 
> 	if (dev->dev->bus->sprom.boardflags_lo & B43_BFL_PACTRL)
> 		max_pwr -= 3; /* minus 0.75 */
> 
> 	if (unlikely(max_pwr >= INT_TO_Q52(30/*dBm*/))) {
> 		b43warn(dev->wl,
> 			"Invalid max-TX-power value in SPROM.\n");
> 		max_pwr = INT_TO_Q52(20); /* fake it */
> 		dev->dev->bus->sprom.maxpwr_bg = max_pwr;
> 	}
> ....
I try to send you a 'maybe regular' patch: this solves the issue; before
the patch, the MSB of the MAC address were overridden by one assignement
inside function ssb_pcmcia_get_invariants(...); here the patch


--- a/drivers/ssb/pcmcia.c
+++ b/drivers/ssb/pcmcia.c
@@ -735,5 +735,5 @@ int ssb_pcmcia_get_invariants(struct ssb_bus *bus,
	/* Fetch the vendor specific tuples. */
	res = pcmcia_loop_tuple(bus->host_pcmcia, SSB_PCMCIA_CIS,
-				ssb_pcmcia_do_get_invariants, sprom);
+				ssb_pcmcia_do_get_invariants, iv);
	if ((res == 0) || (res == -ENOSPC))
		return 0;



From Larry.Finger at lwfinger.net  Wed Feb  2 16:58:55 2011
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Wed, 02 Feb 2011 15:58:55 -0600
Subject: Trouble using bcm4318 compact flash with b43 driver
In-Reply-To: <20110202163002.00005927@unknown>
References: <20110114182113.0000753f@unknown>	<4D309B73.8050402@lwfinger.net>	<20110115080500.00001c48@unknown>	<4D31CDA3.9040304@lwfinger.net>	<20110117110618.0000170f@unknown>	<20110117145106.00001ec8@unknown>	<20110118115855.00007877@unknown>	<4D35A506.3090702@lwfinger.net>	<20110119140328.00002dd2@unknown>	<20110121165137.000016ff@unknown>	<4D39C0B9.8050708@lwfinger.net>	<20110121225408.00003e2c@unknown>	<4D3A050D.3090106@lwfinger.net>	<20110122114834.00007abc@unknown>	<20110201154135.00006f0b@unknown>	<4D486FC0.3020507@lwfinger.net>	<20110202101151.00007105@unknown>	<20110202125529.00002e75@unknown>
	<20110202163002.00005927@unknown>
Message-ID: <4D49D39F.2000700@lwfinger.net>

On 02/02/2011 09:30 AM, dylan cristiani wrote:
> On Wed, 2 Feb 2011 12:55:29 +0100
> dylan cristiani <d.cristiani at idem-tech.it> wrote:
> 
>> On Wed, 2 Feb 2011 10:11:51 +0100
>> dylan cristiani <d.cristiani at idem-tech.it> wrote:
>>
>>> On Tue, 01 Feb 2011 14:40:32 -0600
>>> Larry Finger <Larry.Finger at lwfinger.net> wrote:
>>>
>>>> On 02/01/2011 08:41 AM, dylan cristiani wrote:
>>>>> i have some news: i went back to kernel version 2.6.26 and it
>>>>> worked so i moved forward kernel by kernel and it works till
>>>>> kernel 2.6.32; first kernel that shows up the problem is 2.6.33
>>>>> and, at module loading time i can see for the first time, after
>>>>> loading firmware, the following debug info (don't know if it's
>>>>> helpful but same message happears in every non-working kernel
>>>>> from 2.6.33 to 2.6.37):
>>>>>
>>>>> "b43-phy0 warning: Invalid max-TX-power value in SPROM"
>>>>
>>>> Between 2.6.32 and 2.6.33, there were only 6 patches that touched
>>>> SSB. Two of them (e33761e and 3ba6018) affected SPROM writing, one
>>>> (37ace3d) was only for PCMCIA, and one (ac2752c) only affected
>>>> logging of a core scan. The two remaining are 391ae22 that fixed
>>>> an SDIO typo and 8b45499 that put host pointers in a union should
>>>> be the only ones that needed testing.
>>>>
>>>> Those patches are attached. Try each of them in turn to 2.6.33
>>>> with a 'patch -p1 -R < patch_name' If it doesn't help, use the
>>>> same command without the "-R" to reapply. I'm guessing that
>>>> 8b45499 is more likely to be the problem, and I would try it
>>>> first.
>>>>
>>>> Larry
>>> Hi Larry i tryied to reverte two patches you sent me but nothing
>>> happens; but i discovered interesting behaviour: the mac address of
>>> the module is:
>>> 00:0B:B6....
>>> but starting from 2.6.33 the chip is read as:
>>> 14:0B:B6....
>>> (maybe the '0x14' value could be '20dBm' related to the max-TX-power
>>> value.....); so it seems that the driver is faulty reading the chip
>>> properties from sprom (in fact till the 2.6.32 the mac address was
>>> correct and the max-TX-power warning wasn't issued); i noticed that
>>> into drivers/ssb/pcmcia.c tha way to read properties from the chip
>>> is changed also; hope this helps
>> Hi larry i located the problem: at ssb level the info (MAC,
>> max-TX-power and friends) are ok, while when at b43 driver level there
>> are some data corruption; here comes the log of some debug i put into
>> drivers followed by the code slices where i put the debug; i'm sure
>> i'll find the trouble:
>>
>> boot log
>> ...
>> MMMMAC0 = 0
>> MMMMAC1 = b
>> MMMMAC1 = 6b
>> MMMMAC1 = 1e
>> MMMMAC1 = 3e
>> MMMMAC1 = 86
>>
>> sprom->maxpwr_bg = 76
>>
>> ssb: Sonics Silicon Backplane found on PCMCIA device pcmcia0.0
>>
>> IEEEMMMMAC0 = 14
>> IEEEMMMMAC1 = b
>> IEEEMMMMAC1 = 6b
>> IEEEMMMMAC1 = 1e
>> IEEEMMMMAC1 = 3e
>> IEEEMMMMAC1 = 86
>>
>> b43-phy0: Broadcom 4318 WLAN found (core revision 9)
>> Broadcom 43xx driver loaded [ Features: M, Firmware-ID: FW13 ]
>> Reconfiguring network interfaces... 
>> ip: RTNETLINK answers: File exists 
>> b43 ssb0:0: firmware: requesting b43/ucode5.fw
>> buf=31 a 0loading=1buf=30 a 0loading=0
>> b43 ssb0:0: firmware: requesting b43/pcm5.fw
>> buf=31 a 0loading=1buf=30 a 0loading=0
>> b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
>> buf=31 a 0loading=1buf=30 a 0loading=0
>> b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
>> buf=31 a 0loading=1buf=30 a 0loading=0
>> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
>>
>> phy_g max_pwr_bg = 65535
>>
>> b43-phy0 warning: Invalid max-TX-power value in SPROM.
>> udhcpc (v1.17.4) started
>> Sending discover...
>> phy_g max_pwr_bg = 80
>> Sending discover...
>> Sending discover...
>> No lease, failing
>> .....
>>
>> and here the sources:
>>
>> drivers/ssb/pcmcia.c
>>
>> static int ssb_pcmcia_get_mac(struct pcmcia_device *p_dev,
>> 			tuple_t *tuple,
>> 			void *priv)
>> {
>> 	struct ssb_sprom *sprom = priv;
>>
>> 	if (tuple->TupleData[0] != CISTPL_FUNCE_LAN_NODE_ID)
>> 		return -EINVAL;
>> 	if (tuple->TupleDataLen != ETH_ALEN + 2)
>> 		return -EINVAL;
>> 	if (tuple->TupleData[1] != ETH_ALEN)
>> 		return -EINVAL;
>> 	memcpy(sprom->il0mac, &tuple->TupleData[2], ETH_ALEN);
>>
>> //ssb_log
>> 	printk(KERN_INFO "MMMMAC0 = %x", sprom->il0mac[0]);
>> 	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[1]);
>> 	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[2]);
>> 	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[3]);
>> 	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[4]);
>> 	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[5]);
>> //ssb_log
>>
>> 	return 0;
>> };
>> .....
>>
>> static int ssb_pcmcia_do_get_invariants(struct pcmcia_device *p_dev,
>> 					tuple_t *tuple,
>> 					void *priv)
>> {
>> .....
>>
>> 		sprom->maxpwr_bg = tuple->TupleData[8];
>> //ssb_log
>> 		printk(KERN_INFO "sprom->maxpwr_bg = %d",
>> 		sprom->maxpwr_bg); 
>> //ssb_log
>>
>> ......
>>
>>
>> drivers/net/wireless/b43/main.c
>>
>> static int b43_wireless_init(struct ssb_device *dev)
>> {
>> ....
>>
>> 	if (is_valid_ether_addr(sprom->et1mac))
>> 		SET_IEEE80211_PERM_ADDR(hw, sprom->et1mac);
>> 	else
>> 		SET_IEEE80211_PERM_ADDR(hw, sprom->il0mac);
>>
>> //b43_main_log
>> 	printk(KERN_INFO "IEEEMMMMAC0 = %x", sprom->il0mac[0]);
>> 	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[1]);
>> 	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[2]);
>> 	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[3]);
>> 	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[4]);
>> 	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[5]);
>> //b43_main_log
>>
>> ....
>>
>> drivers/net/wireless/b43/phy_g.c
>>
>>
>> 	/* Estimate the TX power emission based on the TSSI */
>> 	estimated_pwr = b43_gphy_estimate_power_out(dev,
>> average_tssi);
>>
>> 	B43_WARN_ON(phy->type != B43_PHYTYPE_G);
>> 	max_pwr = dev->dev->bus->sprom.maxpwr_bg;
>>
>> //b43_phyg_log
>> 	printk(KERN_INFO "phy_g max_pwr_bg = %d\n", max_pwr);
>> //b43_phyg_log
>>
>> 	if (dev->dev->bus->sprom.boardflags_lo & B43_BFL_PACTRL)
>> 		max_pwr -= 3; /* minus 0.75 */
>>
>> 	if (unlikely(max_pwr >= INT_TO_Q52(30/*dBm*/))) {
>> 		b43warn(dev->wl,
>> 			"Invalid max-TX-power value in SPROM.\n");
>> 		max_pwr = INT_TO_Q52(20); /* fake it */
>> 		dev->dev->bus->sprom.maxpwr_bg = max_pwr;
>> 	}
>> ....
> I try to send you a 'maybe regular' patch: this solves the issue; before
> the patch, the MSB of the MAC address were overridden by one assignement
> inside function ssb_pcmcia_get_invariants(...); here the patch
> 
> 
> --- a/drivers/ssb/pcmcia.c
> +++ b/drivers/ssb/pcmcia.c
> @@ -735,5 +735,5 @@ int ssb_pcmcia_get_invariants(struct ssb_bus *bus,
> 	/* Fetch the vendor specific tuples. */
> 	res = pcmcia_loop_tuple(bus->host_pcmcia, SSB_PCMCIA_CIS,
> -				ssb_pcmcia_do_get_invariants, sprom);
> +				ssb_pcmcia_do_get_invariants, iv);
> 	if ((res == 0) || (res == -ENOSPC))
> 		return 0;

Does this one-liner solve all the problems, or just the MAC address?

Larry


From mb at bu3sch.de  Wed Feb  2 17:40:08 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Wed, 02 Feb 2011 23:40:08 +0100
Subject: Trouble using bcm4318 compact flash with b43 driver
In-Reply-To: <20110202163002.00005927@unknown>
	(sfid-20110202_103008_176343_E21C9E30)
References: <20110114182113.0000753f@unknown>
	<4D309B73.8050402@lwfinger.net> <20110115080500.00001c48@unknown>
	<4D31CDA3.9040304@lwfinger.net> <20110117110618.0000170f@unknown>
	<20110117145106.00001ec8@unknown> <20110118115855.00007877@unknown>
	<4D35A506.3090702@lwfinger.net> <20110119140328.00002dd2@unknown>
	<20110121165137.000016ff@unknown> <4D39C0B9.8050708@lwfinger.net>
	<20110121225408.00003e2c@unknown> <4D3A050D.3090106@lwfinger.net>
	<20110122114834.00007abc@unknown> <20110201154135.00006f0b@unknown>
	<4D486FC0.3020507@lwfinger.net> <20110202101151.00007105@unknown>
	<20110202125529.00002e75@unknown>  <20110202163002.00005927@unknown>
	(sfid-20110202_103008_176343_E21C9E30)
Message-ID: <1296686408.26739.18.camel@maggie>

On Wed, 2011-02-02 at 16:30 +0100, dylan cristiani wrote: 
> --- a/drivers/ssb/pcmcia.c
> +++ b/drivers/ssb/pcmcia.c
> @@ -735,5 +735,5 @@ int ssb_pcmcia_get_invariants(struct ssb_bus *bus,
> 	/* Fetch the vendor specific tuples. */
> 	res = pcmcia_loop_tuple(bus->host_pcmcia, SSB_PCMCIA_CIS,
> -				ssb_pcmcia_do_get_invariants, sprom);
> +				ssb_pcmcia_do_get_invariants, iv);
> 	if ((res == 0) || (res == -ENOSPC))
> 		return 0;

That patch seems right.
I guess that the regression was introduced with the general PCMCIA
changes by Dominik Brodowski back in October.



However...

I do actually have serious trouble to figure out what you're doing.
I'm not saying that there is no bug, but I don't understand what you're
doing to trigger and/or track down the bug.

Let's look at two facts you gave us in previous email:

1) You want to change the PCI IDs. That implies you have a PCI card.
2) You are patching stuff in the PCMCIA code.

These two things are mutually exclusive.
You card is either PCI xor PCMCIA. So only one of these facts can
be true.

If it really is PCMCIA, I'll have to say that the SSB-PCMCIA
SPROM writing code is basically untested. That means I would be
surprised if it worked at all.

PS:
I also want to note that it is wrong to override the SPROM with
an image acquired elsewhere. The SPROM contains important calibration
data that is card-specific. So you cannot take the SPROM from one
card and put it into another. Even if it's exactly the same card type.
You must read SPROM -> modify that image -> write SPROM back.

-- 
Greetings Michael.



From Larry.Finger at lwfinger.net  Wed Feb  2 22:27:11 2011
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Wed, 02 Feb 2011 21:27:11 -0600
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
Message-ID: <4D4A208F.50408@lwfinger.net>

On 02/02/2011 01:50 AM, Dale Walsh wrote:
> On Feb 01, 2011, at 11:28 AM, Larry Finger wrote:
> 
>> On 02/01/2011 05:23 AM, Dale Walsh wrote:
>>> I had a hard drive failure which forced me to perform a fresh/clean
>>> installation of ubuntu 10 on a new drive since the old drive no longer
>>> functions (it was rather old).
>>>
>>> My use of the b43 software is only for modification of the PCI ID's of
>>> the flashrom and the original installation was provided to me on the HD.
>>>
>>> Now I am unable to write the flashrom after the new installation it
>>> always reports "write error: Operation Not Supported" and this is using
>>> the same cards I was flashing before, I even tried using
>>> a previously modified card and I get the same failure.
>>>
>>> Since it worked before I can only conclude that the new software is
>>> broken and the ability to write is a requirement, can someone help me
>>> resolve this please.
>>
>> I do not doubt that the SPROM writing function is broken, but I wonder
>> why you
>> are needing it now. Why was it necessary to rewrite the SPROM in the first
>> place? Once that was done, then it should never need to be done again.
>> Please
>> explain what you did and what you are doing now.
> 
> Since not all cards are created equal I take a card with specific
> features and functionality, change the ID's to my own for use with my
> own custom drivers which provides added functionality for cards with my
> ID's.
> 
> If the cards do not have my ID's they have the basic functionality that
> people are used to seeing, with my ID's they have the ability to run
> in simultaneous dual band mode (2.4ghz and 5ghz adhoc) and I use these
> ID's to ensure that the drivers only work on cards I approve.
> 
> My only need for linux is to rebrand the cards with my ID's.
> 
> If I understood enough about the write mechanism I would forego the b43
> code all together and create an app that reads and writes the flashrom
> but the time involved  in sifting through the ubuntu code due to it's
> source structure makes it a daunting task that turns me off.
> 
> 
> As before when working in the original installation (provided to me as a
> working installation) I would do the following: (both cat and cp fail)
> 
> 
> sudo su; # become root to avoid permission issues
> 
> cd /PATH TO DIR OF ssb_sprom; # I verify ssb_sprom exists in this location
> 
> rmmod b43; # unload the driver
> 
> cat updated_sprom >ssb_sprom; # write the updated file
> 
> 
> This results in write failure under the new installation.
> 
> 
> cp updated_sprom >ssb_sprom
> 
> 
> This also results in a write failure under the new installation.

I'm a little confused as the PCI IDs are not in the SPROM. Using the procedure
you describe, you would be unable to change them.

You say you use Ubuntu 10. Is it 10.04 or 10.10? The earlier one uses kernel
2.6.32, which I have not tested; however, I did try kernels 2.6.34 and 2.6.38.
Both could write the SPROM for a Cardbus device without any problem.

Larry


From d.cristiani at idem-tech.it  Thu Feb  3 03:28:34 2011
From: d.cristiani at idem-tech.it (dylan cristiani)
Date: Thu, 3 Feb 2011 09:28:34 +0100
Subject: Trouble using bcm4318 compact flash with b43 driver
In-Reply-To: <4D49D39F.2000700@lwfinger.net>
References: <20110114182113.0000753f@unknown> <4D309B73.8050402@lwfinger.net>
	<20110115080500.00001c48@unknown> <4D31CDA3.9040304@lwfinger.net>
	<20110117110618.0000170f@unknown> <20110117145106.00001ec8@unknown>
	<20110118115855.00007877@unknown> <4D35A506.3090702@lwfinger.net>
	<20110119140328.00002dd2@unknown> <20110121165137.000016ff@unknown>
	<4D39C0B9.8050708@lwfinger.net> <20110121225408.00003e2c@unknown>
	<4D3A050D.3090106@lwfinger.net> <20110122114834.00007abc@unknown>
	<20110201154135.00006f0b@unknown> <4D486FC0.3020507@lwfinger.net>
	<20110202101151.00007105@unknown> <20110202125529.00002e75@unknown>
	<20110202163002.00005927@unknown> <4D49D39F.2000700@lwfinger.net>
Message-ID: <20110203092834.0000420f@unknown>

On Wed, 02 Feb 2011 15:58:55 -0600
Larry Finger <Larry.Finger at lwfinger.net> wrote:

> On 02/02/2011 09:30 AM, dylan cristiani wrote:
> > On Wed, 2 Feb 2011 12:55:29 +0100
> > dylan cristiani <d.cristiani at idem-tech.it> wrote:
> > 
> >> On Wed, 2 Feb 2011 10:11:51 +0100
> >> dylan cristiani <d.cristiani at idem-tech.it> wrote:
> >>
> >>> On Tue, 01 Feb 2011 14:40:32 -0600
> >>> Larry Finger <Larry.Finger at lwfinger.net> wrote:
> >>>
> >>>> On 02/01/2011 08:41 AM, dylan cristiani wrote:
> >>>>> i have some news: i went back to kernel version 2.6.26 and it
> >>>>> worked so i moved forward kernel by kernel and it works till
> >>>>> kernel 2.6.32; first kernel that shows up the problem is 2.6.33
> >>>>> and, at module loading time i can see for the first time, after
> >>>>> loading firmware, the following debug info (don't know if it's
> >>>>> helpful but same message happears in every non-working kernel
> >>>>> from 2.6.33 to 2.6.37):
> >>>>>
> >>>>> "b43-phy0 warning: Invalid max-TX-power value in SPROM"
> >>>>
> >>>> Between 2.6.32 and 2.6.33, there were only 6 patches that touched
> >>>> SSB. Two of them (e33761e and 3ba6018) affected SPROM writing,
> >>>> one (37ace3d) was only for PCMCIA, and one (ac2752c) only
> >>>> affected logging of a core scan. The two remaining are 391ae22
> >>>> that fixed an SDIO typo and 8b45499 that put host pointers in a
> >>>> union should be the only ones that needed testing.
> >>>>
> >>>> Those patches are attached. Try each of them in turn to 2.6.33
> >>>> with a 'patch -p1 -R < patch_name' If it doesn't help, use the
> >>>> same command without the "-R" to reapply. I'm guessing that
> >>>> 8b45499 is more likely to be the problem, and I would try it
> >>>> first.
> >>>>
> >>>> Larry
> >>> Hi Larry i tryied to reverte two patches you sent me but nothing
> >>> happens; but i discovered interesting behaviour: the mac address
> >>> of the module is:
> >>> 00:0B:B6....
> >>> but starting from 2.6.33 the chip is read as:
> >>> 14:0B:B6....
> >>> (maybe the '0x14' value could be '20dBm' related to the
> >>> max-TX-power value.....); so it seems that the driver is faulty
> >>> reading the chip properties from sprom (in fact till the 2.6.32
> >>> the mac address was correct and the max-TX-power warning wasn't
> >>> issued); i noticed that into drivers/ssb/pcmcia.c tha way to read
> >>> properties from the chip is changed also; hope this helps
> >> Hi larry i located the problem: at ssb level the info (MAC,
> >> max-TX-power and friends) are ok, while when at b43 driver level
> >> there are some data corruption; here comes the log of some debug i
> >> put into drivers followed by the code slices where i put the
> >> debug; i'm sure i'll find the trouble:
> >>
> >> boot log
> >> ...
> >> MMMMAC0 = 0
> >> MMMMAC1 = b
> >> MMMMAC1 = 6b
> >> MMMMAC1 = 1e
> >> MMMMAC1 = 3e
> >> MMMMAC1 = 86
> >>
> >> sprom->maxpwr_bg = 76
> >>
> >> ssb: Sonics Silicon Backplane found on PCMCIA device pcmcia0.0
> >>
> >> IEEEMMMMAC0 = 14
> >> IEEEMMMMAC1 = b
> >> IEEEMMMMAC1 = 6b
> >> IEEEMMMMAC1 = 1e
> >> IEEEMMMMAC1 = 3e
> >> IEEEMMMMAC1 = 86
> >>
> >> b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> >> Broadcom 43xx driver loaded [ Features: M, Firmware-ID: FW13 ]
> >> Reconfiguring network interfaces... 
> >> ip: RTNETLINK answers: File exists 
> >> b43 ssb0:0: firmware: requesting b43/ucode5.fw
> >> buf=31 a 0loading=1buf=30 a 0loading=0
> >> b43 ssb0:0: firmware: requesting b43/pcm5.fw
> >> buf=31 a 0loading=1buf=30 a 0loading=0
> >> b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
> >> buf=31 a 0loading=1buf=30 a 0loading=0
> >> b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
> >> buf=31 a 0loading=1buf=30 a 0loading=0
> >> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> >>
> >> phy_g max_pwr_bg = 65535
> >>
> >> b43-phy0 warning: Invalid max-TX-power value in SPROM.
> >> udhcpc (v1.17.4) started
> >> Sending discover...
> >> phy_g max_pwr_bg = 80
> >> Sending discover...
> >> Sending discover...
> >> No lease, failing
> >> .....
> >>
> >> and here the sources:
> >>
> >> drivers/ssb/pcmcia.c
> >>
> >> static int ssb_pcmcia_get_mac(struct pcmcia_device *p_dev,
> >> 			tuple_t *tuple,
> >> 			void *priv)
> >> {
> >> 	struct ssb_sprom *sprom = priv;
> >>
> >> 	if (tuple->TupleData[0] != CISTPL_FUNCE_LAN_NODE_ID)
> >> 		return -EINVAL;
> >> 	if (tuple->TupleDataLen != ETH_ALEN + 2)
> >> 		return -EINVAL;
> >> 	if (tuple->TupleData[1] != ETH_ALEN)
> >> 		return -EINVAL;
> >> 	memcpy(sprom->il0mac, &tuple->TupleData[2], ETH_ALEN);
> >>
> >> //ssb_log
> >> 	printk(KERN_INFO "MMMMAC0 = %x", sprom->il0mac[0]);
> >> 	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[1]);
> >> 	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[2]);
> >> 	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[3]);
> >> 	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[4]);
> >> 	printk(KERN_INFO "MMMMAC1 = %x", sprom->il0mac[5]);
> >> //ssb_log
> >>
> >> 	return 0;
> >> };
> >> .....
> >>
> >> static int ssb_pcmcia_do_get_invariants(struct pcmcia_device
> >> *p_dev, tuple_t *tuple,
> >> 					void *priv)
> >> {
> >> .....
> >>
> >> 		sprom->maxpwr_bg = tuple->TupleData[8];
> >> //ssb_log
> >> 		printk(KERN_INFO "sprom->maxpwr_bg = %d",
> >> 		sprom->maxpwr_bg); 
> >> //ssb_log
> >>
> >> ......
> >>
> >>
> >> drivers/net/wireless/b43/main.c
> >>
> >> static int b43_wireless_init(struct ssb_device *dev)
> >> {
> >> ....
> >>
> >> 	if (is_valid_ether_addr(sprom->et1mac))
> >> 		SET_IEEE80211_PERM_ADDR(hw, sprom->et1mac);
> >> 	else
> >> 		SET_IEEE80211_PERM_ADDR(hw, sprom->il0mac);
> >>
> >> //b43_main_log
> >> 	printk(KERN_INFO "IEEEMMMMAC0 = %x", sprom->il0mac[0]);
> >> 	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[1]);
> >> 	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[2]);
> >> 	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[3]);
> >> 	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[4]);
> >> 	printk(KERN_INFO "IEEEMMMMAC1 = %x", sprom->il0mac[5]);
> >> //b43_main_log
> >>
> >> ....
> >>
> >> drivers/net/wireless/b43/phy_g.c
> >>
> >>
> >> 	/* Estimate the TX power emission based on the TSSI */
> >> 	estimated_pwr = b43_gphy_estimate_power_out(dev,
> >> average_tssi);
> >>
> >> 	B43_WARN_ON(phy->type != B43_PHYTYPE_G);
> >> 	max_pwr = dev->dev->bus->sprom.maxpwr_bg;
> >>
> >> //b43_phyg_log
> >> 	printk(KERN_INFO "phy_g max_pwr_bg = %d\n", max_pwr);
> >> //b43_phyg_log
> >>
> >> 	if (dev->dev->bus->sprom.boardflags_lo & B43_BFL_PACTRL)
> >> 		max_pwr -= 3; /* minus 0.75 */
> >>
> >> 	if (unlikely(max_pwr >= INT_TO_Q52(30/*dBm*/))) {
> >> 		b43warn(dev->wl,
> >> 			"Invalid max-TX-power value in SPROM.\n");
> >> 		max_pwr = INT_TO_Q52(20); /* fake it */
> >> 		dev->dev->bus->sprom.maxpwr_bg = max_pwr;
> >> 	}
> >> ....
> > I try to send you a 'maybe regular' patch: this solves the issue;
> > before the patch, the MSB of the MAC address were overridden by one
> > assignement inside function ssb_pcmcia_get_invariants(...); here
> > the patch
> > 
> > 
> > --- a/drivers/ssb/pcmcia.c
> > +++ b/drivers/ssb/pcmcia.c
> > @@ -735,5 +735,5 @@ int ssb_pcmcia_get_invariants(struct ssb_bus
> > *bus, /* Fetch the vendor specific tuples. */
> > 	res = pcmcia_loop_tuple(bus->host_pcmcia, SSB_PCMCIA_CIS,
> > -				ssb_pcmcia_do_get_invariants,
> > sprom);
> > +				ssb_pcmcia_do_get_invariants, iv);
> > 	if ((res == 0) || (res == -ENOSPC))
> > 		return 0;
> 
> Does this one-liner solve all the problems, or just the MAC address?
> 
> Larry
as i can see all the problem becuase also the max-TX-power keep the 
righ value; the fact is that now the structure of
ssb_pcmcia_do_get_invariants doesn't waste the one of
ssb_pcmcia_get_mac and viceversa so all fields seems to be right; in
fact i can just see that MAC and max-TX-power are correct and the
wireless module is working very well, but if you want to suggest me
some values to be checked feel free!
Do you think that we must cc also the linux-arm-kernel list?


From d.cristiani at idem-tech.it  Thu Feb  3 03:45:10 2011
From: d.cristiani at idem-tech.it (dylan cristiani)
Date: Thu, 3 Feb 2011 09:45:10 +0100
Subject: Trouble using bcm4318 compact flash with b43 driver
In-Reply-To: <1296686408.26739.18.camel@maggie>
References: <20110114182113.0000753f@unknown> <4D309B73.8050402@lwfinger.net>
	<20110115080500.00001c48@unknown> <4D31CDA3.9040304@lwfinger.net>
	<20110117110618.0000170f@unknown> <20110117145106.00001ec8@unknown>
	<20110118115855.00007877@unknown> <4D35A506.3090702@lwfinger.net>
	<20110119140328.00002dd2@unknown> <20110121165137.000016ff@unknown>
	<4D39C0B9.8050708@lwfinger.net> <20110121225408.00003e2c@unknown>
	<4D3A050D.3090106@lwfinger.net> <20110122114834.00007abc@unknown>
	<20110201154135.00006f0b@unknown> <4D486FC0.3020507@lwfinger.net>
	<20110202101151.00007105@unknown> <20110202125529.00002e75@unknown>
	<20110202163002.00005927@unknown>
	<1296686408.26739.18.camel@maggie>
Message-ID: <20110203094510.00004cac@unknown>

On Wed, 02 Feb 2011 23:40:08 +0100
Michael B?sch <mb at bu3sch.de> wrote:

> On Wed, 2011-02-02 at 16:30 +0100, dylan cristiani wrote: 
> > --- a/drivers/ssb/pcmcia.c
> > +++ b/drivers/ssb/pcmcia.c
> > @@ -735,5 +735,5 @@ int ssb_pcmcia_get_invariants(struct ssb_bus
> > *bus, /* Fetch the vendor specific tuples. */
> > 	res = pcmcia_loop_tuple(bus->host_pcmcia, SSB_PCMCIA_CIS,
> > -				ssb_pcmcia_do_get_invariants,
> > sprom);
> > +				ssb_pcmcia_do_get_invariants, iv);
> > 	if ((res == 0) || (res == -ENOSPC))
> > 		return 0;
> 
> That patch seems right.
> I guess that the regression was introduced with the general PCMCIA
> changes by Dominik Brodowski back in October.
> 
> 
> 
> However...
> 
> I do actually have serious trouble to figure out what you're doing.
> I'm not saying that there is no bug, but I don't understand what
> you're doing to trigger and/or track down the bug.
> 
> Let's look at two facts you gave us in previous email:
> 
> 1) You want to change the PCI IDs. That implies you have a PCI card.
> 2) You are patching stuff in the PCMCIA code.
i'm using PCMCIA module with BCM4318 so the 2 one is the right statement

> 
> These two things are mutually exclusive.
> You card is either PCI xor PCMCIA. So only one of these facts can
> be true.
yes as i told using b43 driver for PCMCIA ans SSB backplane

> 
> If it really is PCMCIA, I'll have to say that the SSB-PCMCIA
> SPROM writing code is basically untested. That means I would be
> surprised if it worked at all.
> 
> PS:
> I also want to note that it is wrong to override the SPROM with
> an image acquired elsewhere. The SPROM contains important calibration
> data that is card-specific. So you cannot take the SPROM from one
> card and put it into another. Even if it's exactly the same card type.
> You must read SPROM -> modify that image -> write SPROM back.
> 
i'm not trying to write to SPROM i noticed that using kernel 2.6.36 i
was seeing the warning message:
"b43-phy0 warning: Invalid max-TX-power value in SPROM"
, then the wlan card didn't associate to AP.

Then i decided to try to migrate forth to 2.6.37 then back to
2.6.34 but problem was still present; then i changed strategy and i went
very very back to 2.6.26 and i noticed that the warning message wasn't
issued and the wlan module associates to AP and worked; so i decided to
migrate, kernel by kernel, to the first one that showed up the
original problem, that was the 2.6.33; so i guessed that there were
somewhere some changes in SPROM reading methods, that were 'wasting'
some structure where those SPROM values were stored; with a big amount
of printk i located the problem then i (hope to have) fixed it; so
resuming it wasn't problem in ovverriding SPROM values but just the way
the driver was reading and storing these values; hope i explained the
issue

-- 
eng. dylan cristiani
idem srl


From mb at bu3sch.de  Thu Feb  3 05:29:13 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Thu, 03 Feb 2011 11:29:13 +0100
Subject: Trouble using bcm4318 compact flash with b43 driver
In-Reply-To: <20110203094510.00004cac@unknown>
	(sfid-20110203_094520_562653_080142E6)
References: <20110114182113.0000753f@unknown>
	<4D309B73.8050402@lwfinger.net> <20110115080500.00001c48@unknown>
	<4D31CDA3.9040304@lwfinger.net> <20110117110618.0000170f@unknown>
	<20110117145106.00001ec8@unknown> <20110118115855.00007877@unknown>
	<4D35A506.3090702@lwfinger.net> <20110119140328.00002dd2@unknown>
	<20110121165137.000016ff@unknown> <4D39C0B9.8050708@lwfinger.net>
	<20110121225408.00003e2c@unknown> <4D3A050D.3090106@lwfinger.net>
	<20110122114834.00007abc@unknown> <20110201154135.00006f0b@unknown>
	<4D486FC0.3020507@lwfinger.net> <20110202101151.00007105@unknown>
	<20110202125529.00002e75@unknown> <20110202163002.00005927@unknown>
	<1296686408.26739.18.camel@maggie>  <20110203094510.00004cac@unknown>
	(sfid-20110203_094520_562653_080142E6)
Message-ID: <1296728953.26739.19.camel@maggie>

On Thu, 2011-02-03 at 09:45 +0100, dylan cristiani wrote: 
> i'm not trying to write to SPROM i noticed that using kernel 2.6.36 i
> was seeing the warning message:
> "b43-phy0 warning: Invalid max-TX-power value in SPROM"
> , then the wlan card didn't associate to AP.

Oh I think I mixed up two threads on the list then. I should pay more
attention before replying. :D

Anyway, I think your patch is right.

-- 
Greetings Michael.



From dale at daleenterprise.com  Thu Feb  3 06:49:57 2011
From: dale at daleenterprise.com (Dale Walsh)
Date: Thu, 3 Feb 2011 06:49:57 -0500
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <4D4A208F.50408@lwfinger.net>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
Message-ID: <16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 02, 2011, at 22:27 PM, Larry Finger wrote:

> On 02/02/2011 01:50 AM, Dale Walsh wrote:
>> On Feb 01, 2011, at 11:28 AM, Larry Finger wrote:
>>
>>> On 02/01/2011 05:23 AM, Dale Walsh wrote:
>>>> I had a hard drive failure which forced me to perform a fresh/clean
>>>> installation of ubuntu 10 on a new drive since the old drive no  
>>>> longer
>>>> functions (it was rather old).
>>>>
>>>> My use of the b43 software is only for modification of the PCI  
>>>> ID's of
>>>> the flashrom and the original installation was provided to me on  
>>>> the HD.
>>>>
>>>> Now I am unable to write the flashrom after the new installation it
>>>> always reports "write error: Operation Not Supported" and this  
>>>> is using
>>>> the same cards I was flashing before, I even tried using
>>>> a previously modified card and I get the same failure.
>>>>
>>>> Since it worked before I can only conclude that the new software is
>>>> broken and the ability to write is a requirement, can someone  
>>>> help me
>>>> resolve this please.
>>>
>>> I do not doubt that the SPROM writing function is broken, but I  
>>> wonder
>>> why you
>>> are needing it now. Why was it necessary to rewrite the SPROM in  
>>> the first
>>> place? Once that was done, then it should never need to be done  
>>> again.
>>> Please
>>> explain what you did and what you are doing now.
>>
>> Since not all cards are created equal I take a card with specific
>> features and functionality, change the ID's to my own for use with my
>> own custom drivers which provides added functionality for cards  
>> with my
>> ID's.
>>
>> If the cards do not have my ID's they have the basic functionality  
>> that
>> people are used to seeing, with my ID's they have the ability to run
>> in simultaneous dual band mode (2.4ghz and 5ghz adhoc) and I use  
>> these
>> ID's to ensure that the drivers only work on cards I approve.
>>
>> My only need for linux is to rebrand the cards with my ID's.
>>
>> If I understood enough about the write mechanism I would forego  
>> the b43
>> code all together and create an app that reads and writes the  
>> flashrom
>> but the time involved  in sifting through the ubuntu code due to it's
>> source structure makes it a daunting task that turns me off.
>>
>>
>> As before when working in the original installation (provided to  
>> me as a
>> working installation) I would do the following: (both cat and cp  
>> fail)
>>
>>
>> sudo su; # become root to avoid permission issues
>>
>> cd /PATH TO DIR OF ssb_sprom; # I verify ssb_sprom exists in this  
>> location
>>
>> rmmod b43; # unload the driver
>>
>> cat updated_sprom >ssb_sprom; # write the updated file
>>
>>
>> This results in write failure under the new installation.
>>
>>
>> cp updated_sprom >ssb_sprom
>>
>>
>> This also results in a write failure under the new installation.
>
> I'm a little confused as the PCI IDs are not in the SPROM. Using  
> the procedure
> you describe, you would be unable to change them.
>
> You say you use Ubuntu 10. Is it 10.04 or 10.10? The earlier one  
> uses kernel
> 2.6.32, which I have not tested; however, I did try kernels 2.6.34  
> and 2.6.38.
> Both could write the SPROM for a Cardbus device without any problem.
>
> Larry

Yes you must be confused since your making those claims.

Perhaps you might wish to look at "ssb-sprom --help".

All the information I can find about modifying the sprom data talk  
about using ssb-sprom to make the changes.

The only thing that I have never been able to make work without  
corrupting the data is the status LED's, if I try to change them the  
card stop working and this test was performed on BCM94321 based cards  
and the test involved only changes to the status LED's so I have  
accepted that some changes are just not possible.

Installed version is 10.04, a CD which was mailed to me by requesting  
it directly from ubuntu.

What is frustrating me is that you are questioning my reasoning for  
requiring this functionality and making claims which you are  
apparently unknowledgeable about rather than focusing on the issue  
which is the failure to write.

I'll download an image for 10.10 and try that, if it works I'll let  
you know.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFNSpZliD9DTPch4RQRAsI1AJ9SybdL8C9MYsNGXe3ROzbnHsgq4QCfXY3x
ioSasOuRF2xx1LalBQdrv70=
=+QjR
-----END PGP SIGNATURE-----


From mb at bu3sch.de  Thu Feb  3 06:59:32 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Thu, 03 Feb 2011 12:59:32 +0100
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	(sfid-20110203_065003_117141_E1A4725F)
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	(sfid-20110203_065003_117141_E1A4725F)
Message-ID: <1296734372.26739.21.camel@maggie>

On Thu, 2011-02-03 at 06:49 -0500, Dale Walsh wrote: 
> >>>> always reports "write error: Operation Not Supported" and this  

I don't see a codepath that could trigger -EOPNOTSUPP in the
latest version of SSB.

-- 
Greetings Michael.



From dale at daleenterprise.com  Thu Feb  3 07:27:06 2011
From: dale at daleenterprise.com (Dale Walsh)
Date: Thu, 3 Feb 2011 07:27:06 -0500
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <1296734372.26739.21.camel@maggie>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	(sfid-20110203_065003_117141_E1A4725F)
	<1296734372.26739.21.camel@maggie>
Message-ID: <BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 03, 2011, at 06:59 AM, Michael B?sch wrote:

> On Thu, 2011-02-03 at 06:49 -0500, Dale Walsh wrote:
>>>>>> always reports "write error: Operation Not Supported" and this
>
> I don't see a codepath that could trigger -EOPNOTSUPP in the
> latest version of SSB.
>
> --  
> Greetings Michael.

Well something is causing the failure and if the ubuntu/linux code- 
base wasn't such a mess I'd go through and fix it myself.

I installed ubuntu 10.10 and it works so there is something in the  
10.04 CD ubuntu sent me that causes the failure so for future  
reference, you can tell them to upgrade to 10.10 and the failure goes  
away.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFNSp8biD9DTPch4RQRAqhUAKCZPvBIwyYU/HvQOd5zOjzafo8w/QCgopI7
jS7yluMV35X4/GPzcLQvWnY=
=Mdkb
-----END PGP SIGNATURE-----


From zajec5 at gmail.com  Thu Feb  3 10:34:31 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Thu, 3 Feb 2011 15:34:31 +0000
Subject: Broadcom 14e4:4727 card
Message-ID: <AANLkTinM3rASTNYw+5vg7gBo5FigRwd1AohVwySQxRhQ@mail.gmail.com>

Hi,

My girlfriend just showed me her new notebook and... wohoo, it
contains 14e4:4727 I couldn't really find or Google! :)

This card is visible as:
03:00.0 Network controller [0280]: Broadcom Corporation BCM4313
802.11b/g LP-PHY [14e4:4727] (rev 01)
however loading ssb debug-less doesn't result in displaying anything in dmesg.

Does it mean this is SSB less Broadcom card? Or is this SSB based but
ssb module can not handle it for some reason? Right now I'm running
just LiveCD, can not recompile ssb modules with debugging enabled.
I'll borrow that card when I'll have something to insert instead (I
didn't take any card with me).

This is surely 802.11n card, so don't focus on lspci output.

-- 
Rafa?


From francesco.gringoli at ing.unibs.it  Thu Feb  3 10:49:34 2011
From: francesco.gringoli at ing.unibs.it (Francesco Gringoli)
Date: Thu, 3 Feb 2011 16:49:34 +0100
Subject: Broadcom 14e4:4727 card
In-Reply-To: <AANLkTinM3rASTNYw+5vg7gBo5FigRwd1AohVwySQxRhQ@mail.gmail.com>
References: <AANLkTinM3rASTNYw+5vg7gBo5FigRwd1AohVwySQxRhQ@mail.gmail.com>
Message-ID: <1EB393CE-CE3E-4DA1-97EF-CD4C62B61A26@ing.unibs.it>

On Feb 3, 2011, at 4:34 PM, Rafa? Mi?ecki wrote:

> Hi,
> 
> My girlfriend just showed me her new notebook and... wohoo, it
> contains 14e4:4727 I couldn't really find or Google! :)
> 
> This card is visible as:
> 03:00.0 Network controller [0280]: Broadcom Corporation BCM4313
> 802.11b/g LP-PHY [14e4:4727] (rev 01)
> however loading ssb debug-less doesn't result in displaying anything in dmesg.
> 
> Does it mean this is SSB less Broadcom card? Or is this SSB based but
> ssb module can not handle it for some reason? Right now I'm running
> just LiveCD, can not recompile ssb modules with debugging enabled.
> I'll borrow that card when I'll have something to insert instead (I
> didn't take any card with me).
> 
> This is surely 802.11n card, so don't focus on lspci output.
Hi Rafa?,

it should one of those devices handled by brcm80211 driver. Did you test it?

Cheers,
-Francesco

> 
> -- 
> Rafa?
> 
> _______________________________________________
> b43-dev mailing list
> b43-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/b43-dev



From s.L-H at gmx.de  Thu Feb  3 10:50:52 2011
From: s.L-H at gmx.de (Stefan Lippers-Hollmann)
Date: Thu, 3 Feb 2011 16:50:52 +0100
Subject: Broadcom 14e4:4727 card
In-Reply-To: <AANLkTinM3rASTNYw+5vg7gBo5FigRwd1AohVwySQxRhQ@mail.gmail.com>
References: <AANLkTinM3rASTNYw+5vg7gBo5FigRwd1AohVwySQxRhQ@mail.gmail.com>
Message-ID: <201102031650.54903.s.L-H@gmx.de>

Hi

On Thursday 03 February 2011, Rafa? Mi?ecki wrote:
> Hi,
> 
> My girlfriend just showed me her new notebook and... wohoo, it
> contains 14e4:4727 I couldn't really find or Google! :)
> 
> This card is visible as:
> 03:00.0 Network controller [0280]: Broadcom Corporation BCM4313
> 802.11b/g LP-PHY [14e4:4727] (rev 01)
> however loading ssb debug-less doesn't result in displaying anything in dmesg.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/staging/brcm80211/README

> Does it mean this is SSB less Broadcom card? Or is this SSB based but
> ssb module can not handle it for some reason? Right now I'm running
> just LiveCD, can not recompile ssb modules with debugging enabled.
> I'll borrow that card when I'll have something to insert instead (I
> didn't take any card with me).

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/staging/brcm80211/sys/wl_mac80211.c;h=f1235884cc5d24f15d3619b8678e0a2751754563;hb=HEAD#l121
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/staging/brcm80211/include/bcmdevs.h;h=075883a935291b58c832038e7fe400a5708edf97;hb=HEAD#l47

So it pretty much looks like being SSB less and using brcm80211 instead.

Regards
	Stefan Lippers-Hollmann


From zajec5 at gmail.com  Thu Feb  3 11:44:56 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Thu, 3 Feb 2011 17:44:56 +0100
Subject: Broadcom 14e4:4727 card
In-Reply-To: <1EB393CE-CE3E-4DA1-97EF-CD4C62B61A26@ing.unibs.it>
References: <AANLkTinM3rASTNYw+5vg7gBo5FigRwd1AohVwySQxRhQ@mail.gmail.com>
	<1EB393CE-CE3E-4DA1-97EF-CD4C62B61A26@ing.unibs.it>
Message-ID: <AANLkTi=29qpxz7Pa7=ffA4qMMeBQ=9_xp6hx-ho8WCjE@mail.gmail.com>

W dniu 3 lutego 2011 16:49 u?ytkownik Francesco Gringoli
<francesco.gringoli at ing.unibs.it> napisa?:
> it should one of those devices handled by brcm80211 driver. Did you test it?

I had only one LiveCD with old kernel. Wiki confused me about this
card being supported LP-PHY. Thanks for reply :)

-- 
Rafa?


From zajec5 at gmail.com  Thu Feb  3 11:45:36 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Thu, 3 Feb 2011 17:45:36 +0100
Subject: Broadcom 14e4:4727 card
In-Reply-To: <201102031650.54903.s.L-H@gmx.de>
References: <AANLkTinM3rASTNYw+5vg7gBo5FigRwd1AohVwySQxRhQ@mail.gmail.com>
	<201102031650.54903.s.L-H@gmx.de>
Message-ID: <AANLkTi=rK_hxN559vmhXOqQUip9vynMnP9DkidhB8xBb@mail.gmail.com>

W dniu 3 lutego 2011 16:50 u?ytkownik Stefan Lippers-Hollmann
<s.L-H at gmx.de> napisa?:
> Hi
>
> On Thursday 03 February 2011, Rafa? Mi?ecki wrote:
>> Hi,
>>
>> My girlfriend just showed me her new notebook and... wohoo, it
>> contains 14e4:4727 I couldn't really find or Google! :)
>>
>> This card is visible as:
>> 03:00.0 Network controller [0280]: Broadcom Corporation BCM4313
>> 802.11b/g LP-PHY [14e4:4727] (rev 01)
>> however loading ssb debug-less doesn't result in displaying anything in dmesg.
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/staging/brcm80211/README
>
>> Does it mean this is SSB less Broadcom card? Or is this SSB based but
>> ssb module can not handle it for some reason? Right now I'm running
>> just LiveCD, can not recompile ssb modules with debugging enabled.
>> I'll borrow that card when I'll have something to insert instead (I
>> didn't take any card with me).
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/staging/brcm80211/sys/wl_mac80211.c;h=f1235884cc5d24f15d3619b8678e0a2751754563;hb=HEAD#l121
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/staging/brcm80211/include/bcmdevs.h;h=075883a935291b58c832038e7fe400a5708edf97;hb=HEAD#l47
>
> So it pretty much looks like being SSB less and using brcm80211 instead.

It seems so, thanks. I'll just focus on SSB cards for now :)

-- 
Rafa?


From Larry.Finger at lwfinger.net  Thu Feb  3 12:05:56 2011
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Thu, 03 Feb 2011 11:05:56 -0600
Subject: Broadcom 14e4:4727 card
In-Reply-To: <AANLkTi=rK_hxN559vmhXOqQUip9vynMnP9DkidhB8xBb@mail.gmail.com>
References: <AANLkTinM3rASTNYw+5vg7gBo5FigRwd1AohVwySQxRhQ@mail.gmail.com>	<201102031650.54903.s.L-H@gmx.de>
	<AANLkTi=rK_hxN559vmhXOqQUip9vynMnP9DkidhB8xBb@mail.gmail.com>
Message-ID: <4D4AE074.80108@lwfinger.net>

On 02/03/2011 10:45 AM, Rafa? Mi?ecki wrote:
> W dniu 3 lutego 2011 16:50 u?ytkownik Stefan Lippers-Hollmann
> <s.L-H at gmx.de> napisa?:
>> Hi
>>
>> On Thursday 03 February 2011, Rafa? Mi?ecki wrote:
>>> Hi,
>>>
>>> My girlfriend just showed me her new notebook and... wohoo, it
>>> contains 14e4:4727 I couldn't really find or Google! :)
>>>
>>> This card is visible as:
>>> 03:00.0 Network controller [0280]: Broadcom Corporation BCM4313
>>> 802.11b/g LP-PHY [14e4:4727] (rev 01)
>>> however loading ssb debug-less doesn't result in displaying anything in dmesg.
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/staging/brcm80211/README
>>
>>> Does it mean this is SSB less Broadcom card? Or is this SSB based but
>>> ssb module can not handle it for some reason? Right now I'm running
>>> just LiveCD, can not recompile ssb modules with debugging enabled.
>>> I'll borrow that card when I'll have something to insert instead (I
>>> didn't take any card with me).
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/staging/brcm80211/sys/wl_mac80211.c;h=f1235884cc5d24f15d3619b8678e0a2751754563;hb=HEAD#l121
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/staging/brcm80211/include/bcmdevs.h;h=075883a935291b58c832038e7fe400a5708edf97;hb=HEAD#l47
>>
>> So it pretty much looks like being SSB less and using brcm80211 instead.
> 
> It seems so, thanks. I'll just focus on SSB cards for now :)

I think that best.

I changed the "support" table to make it more clear that support means that
there is an open-source option available.

Larry


From zajec5 at gmail.com  Thu Feb  3 12:13:46 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Thu, 3 Feb 2011 18:13:46 +0100
Subject: Broadcom 14e4:4727 card
In-Reply-To: <4D4AE074.80108@lwfinger.net>
References: <AANLkTinM3rASTNYw+5vg7gBo5FigRwd1AohVwySQxRhQ@mail.gmail.com>
	<201102031650.54903.s.L-H@gmx.de>
	<AANLkTi=rK_hxN559vmhXOqQUip9vynMnP9DkidhB8xBb@mail.gmail.com>
	<4D4AE074.80108@lwfinger.net>
Message-ID: <AANLkTi=garcK5go9K6zc8v7UPs=DDh7Ux8Tyv+m9wkY-@mail.gmail.com>

W dniu 3 lutego 2011 18:05 u?ytkownik Larry Finger
<Larry.Finger at lwfinger.net> napisa?:
> On 02/03/2011 10:45 AM, Rafa? Mi?ecki wrote:
>> W dniu 3 lutego 2011 16:50 u?ytkownik Stefan Lippers-Hollmann
>> <s.L-H at gmx.de> napisa?:
>>> Hi
>>>
>>> On Thursday 03 February 2011, Rafa? Mi?ecki wrote:
>>>> Hi,
>>>>
>>>> My girlfriend just showed me her new notebook and... wohoo, it
>>>> contains 14e4:4727 I couldn't really find or Google! :)
>>>>
>>>> This card is visible as:
>>>> 03:00.0 Network controller [0280]: Broadcom Corporation BCM4313
>>>> 802.11b/g LP-PHY [14e4:4727] (rev 01)
>>>> however loading ssb debug-less doesn't result in displaying anything in dmesg.
>>>
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/staging/brcm80211/README
>>>
>>>> Does it mean this is SSB less Broadcom card? Or is this SSB based but
>>>> ssb module can not handle it for some reason? Right now I'm running
>>>> just LiveCD, can not recompile ssb modules with debugging enabled.
>>>> I'll borrow that card when I'll have something to insert instead (I
>>>> didn't take any card with me).
>>>
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/staging/brcm80211/sys/wl_mac80211.c;h=f1235884cc5d24f15d3619b8678e0a2751754563;hb=HEAD#l121
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/staging/brcm80211/include/bcmdevs.h;h=075883a935291b58c832038e7fe400a5708edf97;hb=HEAD#l47
>>>
>>> So it pretty much looks like being SSB less and using brcm80211 instead.
>>
>> It seems so, thanks. I'll just focus on SSB cards for now :)
>
> I think that best.
>
> I changed the "support" table to make it more clear that support means that
> there is an open-source option available.

I don't like it. Ppl don't read whole headers and tables, they will be
confused. If someone visits b43 page and sees "supported", he will
expect b43 to support it.

Please make it "brcm80211" supported or sth like that.

Can we add colors to cells? Like:
http://en.wikipedia.org/wiki/Comparison_of_open_source_wireless_drivers
We could use green for cards supported by b43, orange for supported by
brcm80211 and red for not supported by open source driver.

Or maybe even other idea. Make 3 columns: b43, brcm80211, wl. Add info
about support in each driver. What do you think?

-- 
Rafa?


From mb at bu3sch.de  Thu Feb  3 17:06:28 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Thu, 03 Feb 2011 23:06:28 +0100
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	(sfid-20110203_132714_452564_235F4728)
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	(sfid-20110203_065003_117141_E1A4725F)
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	(sfid-20110203_132714_452564_235F4728)
Message-ID: <1296770788.9535.1.camel@maggie>

On Thu, 2011-02-03 at 07:27 -0500, Dale Walsh wrote: 
> Well something is causing the failure and if the ubuntu/linux code- 
> base wasn't such a mess I'd go through and fix it myself.

I'm wondering to what mess you are referring.
I don't think the SPROM writing code is that bad.

> I installed ubuntu 10.10 and it works so there is something in the  
> 10.04 CD ubuntu sent me that causes the failure so for future  
> reference, you can tell them to upgrade to 10.10 and the failure goes  
> away.

I suggest you report this to the Ubuntu bugzilla.

-- 
Greetings Michael.



From peter at stuge.se  Thu Feb  3 17:34:30 2011
From: peter at stuge.se (Peter Stuge)
Date: Thu, 3 Feb 2011 23:34:30 +0100
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <1296770788.9535.1.camel@maggie>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie>
Message-ID: <20110203223430.18158.qmail@stuge.se>

Michael B?sch wrote:
> > Well something is causing the failure and if the ubuntu/linux code- 
> > base wasn't such a mess I'd go through and fix it myself.
> 
> I'm wondering to what mess you are referring.

For someone whose only exposure to Linux is picking up a Ubuntu CD
a Linux system as a whole is a horrible mess. Part of it is the fact
that so many different components (packages if you like) are
involved, and there's no way to document all of that so well in a
single page executive summary, rather it's more like a week
curriculum.


> I don't think the SPROM writing code is that bad.

I believe that the b43 code is really good. Finding it and figuring
out what other code is relevant is the hard part.

It's very easy to explain the neccessary parts to someone skilled,
it's also easy to discover independently for the skilled person, but
doing that discovery alone will take a long time.


//Peter


From mb at bu3sch.de  Thu Feb  3 17:49:50 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Thu, 03 Feb 2011 23:49:50 +0100
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <20110203223430.18158.qmail@stuge.se>
	(sfid-20110203_233436_872866_FFFFFFFFAF4E58C5)
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie> <20110203223430.18158.qmail@stuge.se>
	(sfid-20110203_233436_872866_FFFFFFFFAF4E58C5)
Message-ID: <1296773390.9535.13.camel@maggie>

On Thu, 2011-02-03 at 23:34 +0100, Peter Stuge wrote: 
> Michael B?sch wrote:
> > > Well something is causing the failure and if the ubuntu/linux code- 
> > > base wasn't such a mess I'd go through and fix it myself.
> > 
> > I'm wondering to what mess you are referring.
> 
> For someone whose only exposure to Linux is picking up a Ubuntu CD
> a Linux system as a whole is a horrible mess. Part of it is the fact
> that so many different components (packages if you like) are
> involved, and there's no way to document all of that so well in a
> single page executive summary, rather it's more like a week
> curriculum.

I'm not convinced that this is due to the Linux architecture
or a lack of its documentation.
You're simply unaware of the basic Unix tools that help you find
what you are searching for. Luckily the tool to find something
is called "find".

mb at maggie:~/develop/git/wireless-testing$ find . -name '*sprom*'
./include/config/ssb/sprom.h
./drivers/ssb/sprom.o
./drivers/ssb/sprom.c
./drivers/ssb/.sprom.o.cmd
./arch/mips/include/asm/mipsprom.h

You'll note that this pretty generic "find" run on the _whole_ Linux
kernel yields exactly one .c source file. And guess what, it's the one
you're looking for ;)

> It's very easy to explain the neccessary parts to someone skilled,
> it's also easy to discover independently for the skilled person, but
> doing that discovery alone will take a long time.

Searching the kernel source tree for the term "sprom" isn't rocket
science and doesn't consume much of your valuable time. q.e.d.

If you still think that there's a lack of documentation, please
contribute to the Linux wireless documentation wiki. I'd be happy to
see you share your knowledge with newbies.

-- 
Greetings Michael.



From dale at daleenterprise.com  Thu Feb  3 18:36:22 2011
From: dale at daleenterprise.com (Dale Walsh)
Date: Thu, 3 Feb 2011 18:36:22 -0500
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <1296770788.9535.1.camel@maggie>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	(sfid-20110203_065003_117141_E1A4725F)
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	(sfid-20110203_132714_452564_235F4728)
	<1296770788.9535.1.camel@maggie>
Message-ID: <079FAB8F-1303-41DB-ACC9-D04E284EDDF7@daleenterprise.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 03, 2011, at 17:06 PM, Michael B?sch wrote:

> On Thu, 2011-02-03 at 07:27 -0500, Dale Walsh wrote:
>> Well something is causing the failure and if the ubuntu/linux code-
>> base wasn't such a mess I'd go through and fix it myself.
>
> I'm wondering to what mess you are referring.
> I don't think the SPROM writing code is that bad.

The SPROM writing code itself might not be so bad but the b43 code  
has stuff all over the place and scavenging through all the files  
trying to find the relevant material would require more time that I  
have to get a working solution, not exactly what I'd call cohesive  
when you start looking at code and you have to look all over the  
place to find stuff, my dislike is in the structure or I should state  
lack of.

This is not to say that the package as a whole is not good but having  
to rebuild a kernel to add driver support is in my opinion a poor  
design concept, drivers should be standalone and not require  
additional code inserted in the kernel to obtain functionality.

If I could extract the code and generate a standalone app to perform  
the flash it would make it much easier to resolve write issues.

>> I installed ubuntu 10.10 and it works so there is something in the
>> 10.04 CD ubuntu sent me that causes the failure so for future
>> reference, you can tell them to upgrade to 10.10 and the failure goes
>> away.
>
> I suggest you report this to the Ubuntu bugzilla.

Report what?

It's mentioned that the code is messed up and 10.10 works so what's  
the point in mentioning it again.

> -- 
> Greetings Michael.
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFNSzv3iD9DTPch4RQRAphvAJwI0fqzUziWjdNGOMs56qF3Ns0ZiACZAds8
tcwE4srP+t7ojMhQUgGaOUc=
=U5xc
-----END PGP SIGNATURE-----


From peter at stuge.se  Thu Feb  3 18:47:30 2011
From: peter at stuge.se (Peter Stuge)
Date: Fri, 4 Feb 2011 00:47:30 +0100
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <1296773390.9535.13.camel@maggie>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie>
	<20110203223430.18158.qmail@stuge.se>
	<1296773390.9535.13.camel@maggie>
Message-ID: <20110203234730.28953.qmail@stuge.se>

Michael B?sch wrote:
> > > > Well something is causing the failure and if the ubuntu/linux code- 
> > > > base wasn't such a mess I'd go through and fix it myself.
> > > 
> > > I'm wondering to what mess you are referring.
> > 
> > For someone whose only exposure to Linux is picking up a Ubuntu CD
> > a Linux system as a whole is a horrible mess. Part of it is the fact
> > that so many different components (packages if you like) are
> > involved, and there's no way to document all of that so well in a
> > single page executive summary, rather it's more like a week
> > curriculum.
> 
> I'm not convinced that this is due to the Linux architecture
> or a lack of its documentation.

Now you're moving on to why, which I think doesn't matter.

You asked what mess, I pointed out what I believed was the original
poster's point.

I don't really care why. Personally I also don't really think Linux
is a mess, I find it very structured, but like any modern operating
system the structure can seem really complex when starting out,
simply because there are so many components.


> You're simply unaware of the basic Unix tools that help you find
> what you are searching for.

Not at all. If I was the one looking for the code that talks to
hardware I'd not only know where to find it, but I'd also know every
other component of hardware and software that the data passes through
on the way.


> Luckily the tool to find something is called "find".

I think you may have missed my point. One part is certainly to know
how to find a file in a Linux system, but more important is the
question of what to search for (a file) and where to search (in the
kernel codebase). It's not at all obvious to a newcomer where the
kernel edge is, or even that the kernel is so distinct.


> "find" run on the _whole_ Linux kernel yields exactly one .c source file

Getting to the point where one has a feel for the kernel's scope
already requires a bit of studying of the system.

I've had enough experience training my customers and on a couple
occasions also students to have seen many difficulties in grasping
exactly what the kernel is.


> > It's very easy to explain the neccessary parts to someone skilled,
> > it's also easy to discover independently for the skilled person, but
> > doing that discovery alone will take a long time.
> 
> Searching the kernel source tree for the term "sprom" isn't rocket
> science and doesn't consume much of your valuable time.

Hopefully the above explanation helps clarify that the problem is not
about finding "sprom" in the kernel source. At that point the problem
is, as you point out, quite easily solved. What can take a bit of
time is getting to the point of knowing where to search.


> If you still think that there's a lack of documentation, please
> contribute to the Linux wireless documentation wiki.

I think that would be a total micro-optimization for the case that I
have tried to describe. :\


> I'd be happy to see you share your knowledge with newbies.

It'll make you happy then that I'm happy to share what knowledge I
have. However, it's also important to choose one's battles, and I for
one prefer the lecture format in this case, if only because I can
speak faster than I can type. ;)


//Peter


From peter at stuge.se  Thu Feb  3 18:49:28 2011
From: peter at stuge.se (Peter Stuge)
Date: Fri, 4 Feb 2011 00:49:28 +0100
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <079FAB8F-1303-41DB-ACC9-D04E284EDDF7@daleenterprise.com>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie>
	<079FAB8F-1303-41DB-ACC9-D04E284EDDF7@daleenterprise.com>
Message-ID: <20110203234928.29413.qmail@stuge.se>

Dale Walsh wrote:
>> I suggest you report this to the Ubuntu bugzilla.
>
> Report what?
>
> It's mentioned that the code is messed up and 10.10 works so what's
> the point in mentioning it again.

I'm not sure of how Ubuntu updates work, but maybe 10.04 could get an
update which fixes the problem. Even if that's not relevant for your
10.10 use case it would be a nice thing to do in order to help others
who may potentially run into the same issue, using 10.04.


//Peter


From mb at bu3sch.de  Thu Feb  3 19:17:44 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Fri, 04 Feb 2011 01:17:44 +0100
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <079FAB8F-1303-41DB-ACC9-D04E284EDDF7@daleenterprise.com>
	(sfid-20110204_003632_612620_2DB39BC7)
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	(sfid-20110203_065003_117141_E1A4725F)
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	(sfid-20110203_132714_452564_235F4728) <1296770788.9535.1.camel@maggie>
	<079FAB8F-1303-41DB-ACC9-D04E284EDDF7@daleenterprise.com>
	(sfid-20110204_003632_612620_2DB39BC7)
Message-ID: <1296778664.9535.36.camel@maggie>

On Thu, 2011-02-03 at 18:36 -0500, Dale Walsh wrote: 
> The SPROM writing code itself might not be so bad but the b43 code  
> has stuff all over the place and scavenging through all the files  
> trying to find the relevant material would require more time that I  
> have to get a working solution, not exactly what I'd call cohesive  
> when you start looking at code and you have to look all over the  
> place to find stuff, my dislike is in the structure or I should state  
> lack of.

Claiming a distaste for the spread of code into subsystems and the
lack of structure at the same time is an interesting thing to do...

As I mentioned before: You do not have to dig through all those
files. There are fast and easy to use standard Unix tools that do
this job for you.

> This is not to say that the package as a whole is not good but having  
> to rebuild a kernel to add driver support is in my opinion a poor  
> design concept, drivers should be standalone and not require  
> additional code inserted in the kernel to obtain functionality.

Yeah, and that is why there is absolutely no need to recompile
the kernel, if you want to add a driver. _Especially_ not for wireless.
The Linux wireless developers maintain the compat-wireless package,
which is a major effort for the only purpose of end-user convenience.

> If I could extract the code and generate a standalone app to perform  
> the flash it would make it much easier to resolve write issues.

ssb-sprom basically _is_ the standalone app to perform sprom
modification. For the actual "flashing" (it's not flash)
you'll need kernel support, naturally. There's no sane way around
that requirement. The kernel part is tiny, and you will always need it.

> >> I installed ubuntu 10.10 and it works so there is something in the
> >> 10.04 CD ubuntu sent me that causes the failure so for future
> >> reference, you can tell them to upgrade to 10.10 and the failure goes
> >> away.
> >
> > I suggest you report this to the Ubuntu bugzilla.
> 
> Report what?

Report that SSB SPROM writing is broken in Ubuntu 10.04, so
that Ubuntu developers can fix it. There's no way I can fix that,
because I am an upstream maintainer. And my upstream code is OK
as of latest revision.

> It's mentioned that the code is messed up

For a proper technical conversation it's always a good idea
to avoid unqualified and unproven claims.
That basically leads nowhere, except for aggressive replies.

-- 
Greetings Michael.



From mb at bu3sch.de  Thu Feb  3 19:29:05 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Fri, 04 Feb 2011 01:29:05 +0100
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <20110203234730.28953.qmail@stuge.se>
	(sfid-20110204_004735_721902_FFFFFFFFD8BEB068)
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie> <20110203223430.18158.qmail@stuge.se>
	<1296773390.9535.13.camel@maggie> <20110203234730.28953.qmail@stuge.se>
	(sfid-20110204_004735_721902_FFFFFFFFD8BEB068)
Message-ID: <1296779345.9535.46.camel@maggie>

On Fri, 2011-02-04 at 00:47 +0100, Peter Stuge wrote: 
> > You're simply unaware of the basic Unix tools that help you find
> > what you are searching for.
> 
> Not at all. If I was the one looking for the code that talks to
> hardware I'd not only know where to find it, but I'd also know every
> other component of hardware and software that the data passes through
> on the way.

A basic thing about software abstraction is that you do _not_ need
to know what a subsystem does internally. To understand the ssb_sprom
file, you do _not_ have to read one single line of sysfs code.
To understand the whole SSB SPROM writing, you have to read about 200
lines of code.

> > Luckily the tool to find something is called "find".
> 
> I think you may have missed my point. One part is certainly to know
> how to find a file in a Linux system, but more important is the
> question of what to search for (a file) and where to search (in the
> kernel codebase). It's not at all obvious to a newcomer where the
> kernel edge is, or even that the kernel is so distinct.

I think we're probably drifting offtopic. Why would a newcomer who
doesn't even know what an operating system kernel is want to
write an SSB SPROM? That guy will brick his device anyway, as
he _will_ write incorrect data to the SPROM.

The next thing you'll probably blame on me is that I did not document in
the b43 documentation how to use a qwerty keyboard.

-- 
Greetings Michael.



From peter at stuge.se  Thu Feb  3 20:16:20 2011
From: peter at stuge.se (Peter Stuge)
Date: Fri, 4 Feb 2011 02:16:20 +0100
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <1296779345.9535.46.camel@maggie>
References: <463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie>
	<20110203223430.18158.qmail@stuge.se>
	<1296773390.9535.13.camel@maggie>
	<20110203234730.28953.qmail@stuge.se>
	<1296779345.9535.46.camel@maggie>
Message-ID: <20110204011620.9303.qmail@stuge.se>

Michael B?sch wrote:
> To understand the ssb_sprom file, you do _not_ have to read one
> single line of sysfs code.

Of course. But it can be important to know what sysfs is and what
patterns it uses in order to see a bigger picture.


> To understand the whole SSB SPROM writing, you have to read about
> 200 lines of code.

Yep.


> > It's not at all obvious to a newcomer where the kernel edge is,
> > or even that the kernel is so distinct.
> 
> Why would a newcomer who doesn't even know what an operating system
> kernel is

That's not what I wrote though. I agree with you that it's important
to try to be as accurate as possible.

By "the kernel" I mean Linux. Someone working expertly with a
completely different system may think in the (simplistic) term
Ubuntu. It's a long way from that high-level view into the file with
code that writes the SPROM.


> want to write an SSB SPROM?

As was explained, in this case a Ubuntu system was used as a tool in
a production process.


> That guy will brick his device anyway, as he _will_ write incorrect
> data to the SPROM.

I think it's possible to find a person who knows nearly every bit in
the SPROM, but who knows nothing about Linux. I don't think there's
correlation between the two.


> The next thing you'll probably blame on me is that I did not
> document in the b43 documentation how to use a qwerty keyboard.

I have not and do not blame anything on you.

I think you're being much too sensitive about what I wrote. It was
clear (to me) that you snapped into defensive mode, and that's
unfortunate since I do not believe anyone was attacking you.
(I.e. saying something like Martin is stupid, Martin writes bad code,
or it's Martin's fault that this code does not work on this Ubuntu
version. I certainly don't suggest any of that.)

I don't think that it's your fault that Linux systems are sometimes
complex beasts.. :)


//Peter


From dale at daleenterprise.com  Thu Feb  3 22:14:52 2011
From: dale at daleenterprise.com (Dale Walsh)
Date: Thu, 3 Feb 2011 22:14:52 -0500
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <1296779345.9535.46.camel@maggie>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie>
	<20110203223430.18158.qmail@stuge.se>
	<1296773390.9535.13.camel@maggie>
	<20110203234730.28953.qmail@stuge.se>
	(sfid-20110204_004735_721902_FFFFFFFFD8BEB068)
	<1296779345.9535.46.camel@maggie>
Message-ID: <C038DB15-6427-46CC-A730-1A39CE6B9317@daleenterprise.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 03, 2011, at 19:29 PM, Michael B?sch wrote:

> On Fri, 2011-02-04 at 00:47 +0100, Peter Stuge wrote:
>>> You're simply unaware of the basic Unix tools that help you find
>>> what you are searching for.
>>
>> Not at all. If I was the one looking for the code that talks to
>> hardware I'd not only know where to find it, but I'd also know every
>> other component of hardware and software that the data passes through
>> on the way.
>
> A basic thing about software abstraction is that you do _not_ need
> to know what a subsystem does internally. To understand the ssb_sprom
> file, you do _not_ have to read one single line of sysfs code.
> To understand the whole SSB SPROM writing, you have to read about 200
> lines of code.

I see so if I can compile the ssb-sprom program I am able to perform  
"flashing" of SPROM's on various Broadcom based wireless cards  
without doing anything else, not likely since the kernel may not have  
the required support or functionality.

A kernel compiled without the included dependancies and features  
doesn't support it and the linux based OS I am familiar with doesn't  
require rebuilding the kernel to add support or functionality to do  
anything but is not compatible with the the general linux  
distributions drivers.

My opinion is that there shouldn't be any dependent code in the  
kernel to perform these flashing tasks.

Finding all the code that relates to the Broadcom wireless device and  
it's functionality should be inclusive in the b43 code, having to  
look outside this code to find code that performs the flashing makes  
no sense and the use of nested abstraction layers and code buried in  
structs for functionality only makes it difficult for a person not  
familiar with the code base to locate anything and my opinion is  
there should be no need to look outside the b43 code.

You say you don't have to recompile the kernel to add support for  
things, I remember initially working with ubuntu 8.01 and having to  
recompile the kernel to add support for the Broadcom wireless cards  
because downloading and installing a wireless kernel package someone  
else made that only allowed flashing of some cards was useless.

Rewriting the nVidia drivers was something else I did since 8.0.1  
didn't seem to support multiple cards and having to install a blob  
provided by nvidia to make the card work and seeing this popup  
explaining the license of the third-party (nVidia) software was a  
waste of time so this was dumped in favor of my own code which  
included a HAL source file for the 6k and 7k series cards, not  
exactly legally obtained.

After my 8.01 experience I decided that if the OS doesn't come with  
the required support it's of no value to me, when the working 10 was  
provided on disk I didn't have to do anything or at the very least  
only minimal before flashing and since no instructions were provided  
telling me that I had to do anything other but reinstall the software  
I expected it to work as intended.

Since it seems that wireless support is now pretty much included it's  
improving but when stuff doesn't work, someone involved should be  
knowledgeable enough to know why and or to suggest commands that  
might help isolate the cause of the failure, it might have been user  
induced but it appears that after the installation of 10.10 we can  
conclude it's not a user related error since it works properly.


>
>>> Luckily the tool to find something is called "find".

You can tell "find" to find only the code specifically related to  
flashing SPROM's???

>>
>> I think you may have missed my point. One part is certainly to know
>> how to find a file in a Linux system, but more important is the
>> question of what to search for (a file) and where to search (in the
>> kernel codebase). It's not at all obvious to a newcomer where the
>> kernel edge is, or even that the kernel is so distinct.
>
> I think we're probably drifting offtopic. Why would a newcomer who
> doesn't even know what an operating system kernel is want to
> write an SSB SPROM? That guy will brick his device anyway, as
> he _will_ write incorrect data to the SPROM.

Making assumptions about some ones knowledge or experience is not a  
good thing and I have revealed nothing that would make any  
intelligent person conclude this with them first asking pertinent  
questions.

Stating I will brick cards because you lack the capacity to  
distinguish intelligence from frustration doesn't look good on you  
and you should have asked questions before making such a grand  
assumption, I have flashed more than 10,000 cards and have not  
bricked one, I have had cards that I have tried to alter LED behavior  
stop functioning because they have unsupported firmware versions that  
the application doesn't properly support but I understand that there  
is a risk involved in making changes so I limit my changes to avoid  
that conundrum.

When you can decode a DXE from an intel motherboard BIOS, contact me,  
we might have something we can discuss.

> The next thing you'll probably blame on me is that I did not  
> document in
> the b43 documentation how to use a qwerty keyboard.
> -- 
> Greetings Michael.
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFNS28siD9DTPch4RQRArguAJwKOPyljoMsinW0P2SXR0X1UzN3VACfS75E
fPwdXvX5/8BCM6IYyoIl/UI=
=T6qS
-----END PGP SIGNATURE-----


From richardvoigt at gmail.com  Fri Feb  4 00:49:38 2011
From: richardvoigt at gmail.com (richardvoigt at gmail.com)
Date: Thu, 3 Feb 2011 23:49:38 -0600
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <C038DB15-6427-46CC-A730-1A39CE6B9317@daleenterprise.com>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie>
	<20110203223430.18158.qmail@stuge.se>
	<1296773390.9535.13.camel@maggie>
	<20110203234730.28953.qmail@stuge.se>
	<1296779345.9535.46.camel@maggie>
	<C038DB15-6427-46CC-A730-1A39CE6B9317@daleenterprise.com>
Message-ID: <AANLkTinwd78AvXH5qy3+q3Y+_WecX4dcfnQzY5wQ3JUn@mail.gmail.com>

> You say you don't have to recompile the kernel to add support for things, I
> remember initially working with ubuntu 8.01 and having to recompile the
> kernel to add support for the Broadcom wireless cards because downloading
> and installing a wireless kernel package someone else made that only allowed
> flashing of some cards was useless.

This is not something you need to recompile the kernel to do.  You do
need the kernel source code (check your package manager) and the
config used by the running kernel (available in a pseudo-file) and
that's enough to do an out-of-tree build of your driver.

The idea that a user-mode application should be able to update
firmware without kernel help is patently ridiculous no matter what
(modern general-purpose) operating system you are expert in, since it
requires I/O privileges that are not held by user-mode applications.
But such an application can be distributed with the source code and
build system for an out-of-tree build of the relevant kernel code, in
which case administrator rights will be needed to insert the kernel
module, but the installation process needn't involve replacing any
boot files as would be done after a kernel recompile.


From mb at bu3sch.de  Fri Feb  4 06:20:55 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Fri, 04 Feb 2011 12:20:55 +0100
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <C038DB15-6427-46CC-A730-1A39CE6B9317@daleenterprise.com>
	(sfid-20110203_221456_874114_36A0BE2C)
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie> <20110203223430.18158.qmail@stuge.se>
	<1296773390.9535.13.camel@maggie> <20110203234730.28953.qmail@stuge.se>
	(sfid-20110204_004735_721902_FFFFFFFFD8BEB068)
	<1296779345.9535.46.camel@maggie>
	<C038DB15-6427-46CC-A730-1A39CE6B9317@daleenterprise.com>
	(sfid-20110203_221456_874114_36A0BE2C)
Message-ID: <1296818455.19557.11.camel@maggie>

On Thu, 2011-02-03 at 22:14 -0500, Dale Walsh wrote: 
> I see so if I can compile the ssb-sprom program I am able to perform  
> "flashing" of SPROM's on various Broadcom based wireless cards  
> without doing anything else, not likely since the kernel may not have  
> the required support or functionality.
> 
> A kernel compiled without the included dependancies and features  
> doesn't support it and the linux based OS I am familiar with doesn't  
> require rebuilding the kernel to add support or functionality to do  
> anything but is not compatible with the the general linux  
> distributions drivers.
> 
> My opinion is that there shouldn't be any dependent code in the  
> kernel to perform these flashing tasks.
> 
> Finding all the code that relates to the Broadcom wireless device and  
> it's functionality should be inclusive in the b43 code, having to  
> look outside this code to find code that performs the flashing makes  
> no sense and the use of nested abstraction layers and code buried in  
> structs for functionality only makes it difficult for a person not  
> familiar with the code base to locate anything and my opinion is  
> there should be no need to look outside the b43 code.

Wow, it's really funny to read your mail.
That stuff is so clueless and ridiculous... You must be the
master troll.

I do actually remember why I put you into my mailfilters back in 2008.
I did one mistake, however. I later reinstalled the machine and did
not put the filters back.

To say once again what I already said in 2008:
We are not your personal support army for your questionable business.

-- 
Greetings Michael.



From dale at daleenterprise.com  Fri Feb  4 07:06:16 2011
From: dale at daleenterprise.com (Dale Walsh)
Date: Fri, 4 Feb 2011 07:06:16 -0500
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <AANLkTinwd78AvXH5qy3+q3Y+_WecX4dcfnQzY5wQ3JUn@mail.gmail.com>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie>
	<20110203223430.18158.qmail@stuge.se>
	<1296773390.9535.13.camel@maggie>
	<20110203234730.28953.qmail@stuge.se>
	<1296779345.9535.46.camel@maggie>
	<C038DB15-6427-46CC-A730-1A39CE6B9317@daleenterprise.com>
	<AANLkTinwd78AvXH5qy3+q3Y+_WecX4dcfnQzY5wQ3JUn@mail.gmail.com>
Message-ID: <20AF06EF-A5CC-4944-8C9D-26A451A37AE4@daleenterprise.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 04, 2011, at 00:49 AM, richardvoigt at gmail.com wrote:

>> You say you don't have to recompile the kernel to add support for  
>> things, I
>> remember initially working with ubuntu 8.01 and having to  
>> recompile the
>> kernel to add support for the Broadcom wireless cards because  
>> downloading
>> and installing a wireless kernel package someone else made that  
>> only allowed
>> flashing of some cards was useless.
>
> This is not something you need to recompile the kernel to do.  You do
> need the kernel source code (check your package manager) and the
> config used by the running kernel (available in a pseudo-file) and
> that's enough to do an out-of-tree build of your driver.
>
> The idea that a user-mode application should be able to update
> firmware without kernel help is patently ridiculous no matter what
> (modern general-purpose) operating system you are expert in, since it
> requires I/O privileges that are not held by user-mode applications.
> But such an application can be distributed with the source code and
> build system for an out-of-tree build of the relevant kernel code, in
> which case administrator rights will be needed to insert the kernel
> module, but the installation process needn't involve replacing any
> boot files as would be done after a kernel recompile.
>

I made no claim that kernel help was not required to perform a task,  
I only know what I have experienced in the past regarding flashing  
Broadcom devices.

If that really is the case, then why when building and installing it  
does it create such a large package and install a kernel and support  
files and modify the grub menu rather than install just the required  
driver and application and allow it to function regardless of the  
selected kernel?

When I was working in 8.01 the application and b43 driver alone was  
insufficient to allow flashing, this may be different in newer  
versions but at that time I was unable to make it work without  
installing all kinds of stuff (the full pkg) and selecting the  
modified kernel in the boot loader menu in order to flash the cards  
otherwise it refused to write to any of the BCM94321 I had claiming  
it was an unsupported PHY and would not allow operation on it.

As I recall further, I had to make patches to disable certain checks  
so it would allow writing to any Broadcom cards rather than certain  
cards and some simple apps to change the ID's in the file and  
recalculate the checksum were simple since this is the only required  
changes, I don't need to know what the other bytes represent since  
these are not being altered.

I've worked in FreeBSD, Darwin (not Mac OS X) and Mac OS X and I have  
never had any issues accessing kernel or user space or even modifying  
protected resources or memory on the fly.

There are API's and frameworks to handle those accesses and it's a  
matter of utilizing the correct framework.

I've converted all kinds of drivers from the ubuntu tree to run under  
Mac OS X and for the most part the majority of the code is discarded  
due to the specific kernel ties.

I wrote an application to take existing nVidia SPROM firmware image  
form the card, generate an EFI compatible firmware image, merge the  
two images, correct checksums and firmware size and then reflash the  
card (as long as the SPROM is large enough to contain the new image)  
occurs in about 800 lines of C code and no driver is required to be  
loaded, it finds the device on the PCI bus by ID and there is nothing  
in the ubuntu tree that contains this functionality otherwise I would  
have borrowed it.


If you wish to knit-pick over details knock yourself out but you need  
to stop making assumptions about what I know and don't know.

Explaining in great detail serves no real purpose other than bragging  
and I really have nothing to contribute to the b43 driver or ubuntu  
so explicit details on the b43 code is of no concern to me, it either  
works or it doesn't, if it doesn't then I look for a solution, if it  
does then I have a flashing solution and don't need to look further.

It also seems that people involved with these projects are too  
sensitive, if you don't say something just right or don't mention  
something they get bent out of shape and go off attacking people  
labeling them as morons and idiots, very professional for someone  
involved in a public project who goal is to support the code they  
provide.

I'm not familiar with the code base because after looking at all the  
files I've personally decided it's a structured mess and I will go to  
the group responsible for a particular piece of code when I have  
issues rather than waste months of time learning the code base so I  
can fix it myself, far too time consuming for something that serves a  
single purpose and needs to work immediately.

If there was no solution then I would have to spend the time creating  
something but re-inventing the wheel is an exercise in poor time  
management when time is not something you have.

10.04 is broken, 10.10 works, and this satisfies me, going back and  
playing with 10.04 to find out why or playing with an upgrade path is  
not something I have time for and the condescending attitudes makes  
it less attractive.

If someone else comes experiencing this issue you can inform them  
that 10.10 works as verified by others as well and that should pretty  
much be the end of it unless they have the time and want to spend the  
time digging further but I would suggest curbing the attitude and  
taking a more relaxed approach if you really want to receive  
assistance in debugging things.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFNS+u4iD9DTPch4RQRAiktAKCXXcspz5QJrMxln4rociQScPyMVACfWDT6
TZBLZD8AA0yTpU799s4/DkE=
=cbz0
-----END PGP SIGNATURE-----


From dale at daleenterprise.com  Fri Feb  4 07:17:26 2011
From: dale at daleenterprise.com (Dale Walsh)
Date: Fri, 4 Feb 2011 07:17:26 -0500
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <1296818455.19557.11.camel@maggie>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie>
	<20110203223430.18158.qmail@stuge.se>
	<1296773390.9535.13.camel@maggie>
	<20110203234730.28953.qmail@stuge.se>
	(sfid-20110204_004735_721902_FFFFFFFFD8BEB068)
	<1296779345.9535.46.camel@maggie>
	<C038DB15-6427-46CC-A730-1A39CE6B9317@daleenterprise.com>
	(sfid-20110203_221456_874114_36A0BE2C)
	<1296818455.19557.11.camel@maggie>
Message-ID: <F7733BBE-DFBC-4054-98D0-FB909DD14123@daleenterprise.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 04, 2011, at 06:20 AM, Michael B?sch wrote:

> On Thu, 2011-02-03 at 22:14 -0500, Dale Walsh wrote:
>> I see so if I can compile the ssb-sprom program I am able to perform
>> "flashing" of SPROM's on various Broadcom based wireless cards
>> without doing anything else, not likely since the kernel may not have
>> the required support or functionality.
>>
>> A kernel compiled without the included dependancies and features
>> doesn't support it and the linux based OS I am familiar with doesn't
>> require rebuilding the kernel to add support or functionality to do
>> anything but is not compatible with the the general linux
>> distributions drivers.
>>
>> My opinion is that there shouldn't be any dependent code in the
>> kernel to perform these flashing tasks.
>>
>> Finding all the code that relates to the Broadcom wireless device and
>> it's functionality should be inclusive in the b43 code, having to
>> look outside this code to find code that performs the flashing makes
>> no sense and the use of nested abstraction layers and code buried in
>> structs for functionality only makes it difficult for a person not
>> familiar with the code base to locate anything and my opinion is
>> there should be no need to look outside the b43 code.
>
> Wow, it's really funny to read your mail.
> That stuff is so clueless and ridiculous... You must be the
> master troll.
>
> I do actually remember why I put you into my mailfilters back in 2008.
> I did one mistake, however. I later reinstalled the machine and did
> not put the filters back.
>
> To say once again what I already said in 2008:
> We are not your personal support army for your questionable business.
>
> --  
> Greetings Michael.

Support the code you provide publicly is your purpose, me fixing it  
for you is not support.

What questionable business?

It's against the law to modify a cards ID's?

You like the ubuntu code base and that is your choice, mine is  
different, I believe it suffers from poor management and it is not  
your place to dictate what my opinion should be.

Since you acknowledge you are responsible for this b43 code then make  
sure it works and I wont have to come asking why it doesn't and why  
you broke it, or are you now acknowledging that it's not sound code  
and is questionable if it works type of software?

You know what, no need to respond, you have nothing intelligent to  
add as evident of your responses so do yourself a favor and don't  
bother and it will die off.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFNS+5WiD9DTPch4RQRAgaSAJ4pU3bhBFOY/ehD4xSDO3pYr7zwagCghYsI
kTzJpdRSJH5CtJ1mIcUeM/E=
=g6E+
-----END PGP SIGNATURE-----


From mb at bu3sch.de  Fri Feb  4 07:21:37 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Fri, 04 Feb 2011 13:21:37 +0100
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <20AF06EF-A5CC-4944-8C9D-26A451A37AE4@daleenterprise.com>
	(sfid-20110204_070621_977672_615B1101)
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie> <20110203223430.18158.qmail@stuge.se>
	<1296773390.9535.13.camel@maggie> <20110203234730.28953.qmail@stuge.se>
	<1296779345.9535.46.camel@maggie>
	<C038DB15-6427-46CC-A730-1A39CE6B9317@daleenterprise.com>
	<AANLkTinwd78AvXH5qy3+q3Y+_WecX4dcfnQzY5wQ3JUn@mail.gmail.com>
	<20AF06EF-A5CC-4944-8C9D-26A451A37AE4@daleenterprise.com>
	(sfid-20110204_070621_977672_615B1101)
Message-ID: <1296822097.19557.24.camel@maggie>

On Fri, 2011-02-04 at 07:06 -0500, Dale Walsh wrote: 
> If you wish to knit-pick over details knock yourself out but you need  
> to stop making assumptions about what I know and don't know.

No. You really just need to stop guessing around.

> Explaining in great detail serves no real purpose

I already figured out that you're not interested in falsifications of
your flawed logics.

> It also seems that people involved with these projects are too  
> sensitive, if you don't say something just right or don't mention  
> something they get bent out of shape and go off attacking people  
> labeling them as morons and idiots, very professional for someone  
> involved in a public project who goal is to support the code they  
> provide.

Please quote me with context saying that you're a moron or an idiot.

YOU are the one getting personal. YOU are the one who claimed in
the first place that our software was crap.

> I'm not familiar with the code base because after looking at all the  
> files I've personally decided it's a structured mess

See?

-- 
Greetings Michael.



From mb at bu3sch.de  Fri Feb  4 11:55:26 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Fri, 04 Feb 2011 17:55:26 +0100
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <F7733BBE-DFBC-4054-98D0-FB909DD14123@daleenterprise.com>
	(sfid-20110204_071731_855077_8D4037D1)
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie> <20110203223430.18158.qmail@stuge.se>
	<1296773390.9535.13.camel@maggie> <20110203234730.28953.qmail@stuge.se>
	(sfid-20110204_004735_721902_FFFFFFFFD8BEB068)
	<1296779345.9535.46.camel@maggie>
	<C038DB15-6427-46CC-A730-1A39CE6B9317@daleenterprise.com>
	(sfid-20110203_221456_874114_36A0BE2C)
	<1296818455.19557.11.camel@maggie>
	<F7733BBE-DFBC-4054-98D0-FB909DD14123@daleenterprise.com>
	(sfid-20110204_071731_855077_8D4037D1)
Message-ID: <1296838526.1614.13.camel@Nokia-N900>

> Support the code you provide publicly is your purpose, me fixing it?  
> for you is not support.

So far there was no fix needed, because it's not broken.

> What questionable business?
>
> It's against the law to modify a cards ID's?

Don't get me started with "law". You're distributing quite a few interresting files on your public http server's download area.

> You like the ubuntu code base and that is your choice,

i did not say that.
?  
> different, I believe it suffers from poor management and it is not?  
> your place to dictate what my opinion should be.
>
> Since you acknowledge you are responsible for this b43 code then make

no i don't. i currently am the ssb maintainer.

> You know what, no need to respond, you have nothing intelligent to?  
> add as evident of your responses

as I said. You are the one who drives this discussion into the nontechnical corner.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110204/770bb988/attachment.html>

From zajec5 at gmail.com  Fri Feb  4 13:56:44 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Fri, 4 Feb 2011 19:56:44 +0100
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
Message-ID: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>

I'd like to propose little (nothing big) reogranisation of b43 hardware table:
http://wireless.kernel.org/Zajec?action=recall&rev=4

Changed columns support/supported and driver/alternatives.

Are you fine with that? Can we use colored one?

-- 
Rafa?


From Larry.Finger at lwfinger.net  Fri Feb  4 14:37:57 2011
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Fri, 04 Feb 2011 13:37:57 -0600
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
Message-ID: <4D4C5595.7060903@lwfinger.net>

On 02/04/2011 12:56 PM, Rafa? Mi?ecki wrote:
> I'd like to propose little (nothing big) reogranisation of b43 hardware table:
> http://wireless.kernel.org/Zajec?action=recall&rev=4
> 
> Changed columns support/supported and driver/alternatives.
> 
> Are you fine with that? Can we use colored one?

I like the colored one.

Some small changes:

I would eliminate the second 14e4:4312 line and move the wl entry to the first
one. I don't know if wl supports 5 GHz on that chip. I don't have mine any longer.

On the 4315, make it "(PIO mode for some systems)". I have two of them and both
work fine with DMA mode in b43.

The entry for 14e4:4324 is out of numerical order.

To champion the open-source cause, I would put brcm80211 ahead of wl whenever
both drive a particular chip.

Larry


From mb at bu3sch.de  Fri Feb  4 15:42:20 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Fri, 04 Feb 2011 21:42:20 +0100
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	(sfid-20110204_135646_223572_24A9CBBE)
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	(sfid-20110204_135646_223572_24A9CBBE)
Message-ID: <1296852140.1614.19.camel@Nokia-N900>

> Are you fine with that? Can we use colored one?

Looks good. We could remove "PIO-only" references from LPPHY devs. That seems outdated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110204/e24d8bd0/attachment.html>

From zajec5 at gmail.com  Fri Feb  4 15:27:45 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Fri, 4 Feb 2011 21:27:45 +0100
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <4D4C5595.7060903@lwfinger.net>
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	<4D4C5595.7060903@lwfinger.net>
Message-ID: <AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>

W dniu 4 lutego 2011 20:37 u?ytkownik Larry Finger
<Larry.Finger at lwfinger.net> napisa?:
> On 02/04/2011 12:56 PM, Rafa? Mi?ecki wrote:
>> I'd like to propose little (nothing big) reogranisation of b43 hardware table:
>> http://wireless.kernel.org/Zajec?action=recall&rev=4
>>
>> Changed columns support/supported and driver/alternatives.
>>
>> Are you fine with that? Can we use colored one?
>
> I like the colored one.
>
> Some small changes:
>
> I would eliminate the second 14e4:4312 line and move the wl entry to the first
> one. I don't know if wl supports 5 GHz on that chip. I don't have mine any longer.

Do you know anything about that duplicated ID? Is that true at all?
Why we don't support device with that duplicated ID? Why do you want
to remove it?

-- 
Rafa?


From dale at daleenterprise.com  Fri Feb  4 16:38:16 2011
From: dale at daleenterprise.com (Dale Walsh)
Date: Fri, 4 Feb 2011 16:38:16 -0500
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <1296822097.19557.24.camel@maggie>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie>
	<20110203223430.18158.qmail@stuge.se>
	<1296773390.9535.13.camel@maggie>
	<20110203234730.28953.qmail@stuge.se>
	<1296779345.9535.46.camel@maggie>
	<C038DB15-6427-46CC-A730-1A39CE6B9317@daleenterprise.com>
	<AANLkTinwd78AvXH5qy3+q3Y+_WecX4dcfnQzY5wQ3JUn@mail.gmail.com>
	<20AF06EF-A5CC-4944-8C9D-26A451A37AE4@daleenterprise.com>
	(sfid-20110204_070621_977672_615B1101)
	<1296822097.19557.24.camel@maggie>
Message-ID: <4D27236F-1DEC-464C-836B-A8DD2B911D07@daleenterprise.com>

Be smart, let it go.


On Feb 04, 2011, at 07:21 AM, Michael B?sch wrote:

> On Fri, 2011-02-04 at 07:06 -0500, Dale Walsh wrote:
>> If you wish to knit-pick over details knock yourself out but you need
>> to stop making assumptions about what I know and don't know.
>
> No. You really just need to stop guessing around.

What guessing?

>
>> Explaining in great detail serves no real purpose
>
> I already figured out that you're not interested in falsifications of
> your flawed logics.

More dribble which has nothing to do with your code not working in  
ubuntu 10.04.

>> It also seems that people involved with these projects are too
>> sensitive, if you don't say something just right or don't mention
>> something they get bent out of shape and go off attacking people
>> labeling them as morons and idiots, very professional for someone
>> involved in a public project who goal is to support the code they
>> provide.
>
> Please quote me with context saying that you're a moron or an idiot.


Are you really that slow that you don't know and can't recall what  
you wrote or see the implications when you state what you believe to  
be factual without foundation?

If I put my car key in the ignition of my car, turn it and nothing  
happens I call the dealer because it's obviously broken.

You most likely would interpret that statement to be only what is  
stated and have some smart-assed comment that implies I'm not smart  
enough to determine if there is an electrical issue such as a dead  
battery preventing the car from starting or I didn't turn the key far  
enough and I conclude this based on the way in which you respond not  
only to me but others.

--- START OF QUOTE ---
On Feb 03, 2011, at 19:29 PM, Michael B?sch wrote:

> That guy will brick his device anyway, as
> he _will_ write incorrect data to the SPROM.

--- END OF QUOTE ---



> YOU are the one getting personal. YOU are the one who claimed in
> the first place that our software was crap.
>
>> I'm not familiar with the code base because after looking at all the
>> files I've personally decided it's a structured mess
>
> See?

I specifically state it is my personal decision regarding the state  
of the source tree, are you now accepting responsibility for the  
entire ubuntu source tree?

The remark does not attack your code and I am not the only person who  
has a poor opinion regarding the state of the ubuntu source tree.

If you want to be responsible for a public project that offers public  
support that's great but expect that issue will come up and people  
will expect support and this has nothing to do with the purpose for  
which they use the software, my opinion is this,  it's a public  
project which offers support and you seem to be the leader so, if  
it's broke, fix it, if it isn't broke attempt to help the user in a  
kind and courteous manner and if you can't be kind and courteous  
don't involve yourself in assisting them, they are already frustrated  
enough by the fact that the software doesn't work the way they expect  
it to that they don't need to be further aggravated by a person  
offering support.

> -- 
> Greetings Michael.

My comments about you are generalized and in defense of not only  
remarks and statements you have made towards me but also others.

You really don't appear to have enough common sense to let things go  
and believe you have made no attacks on anyone at any time which is  
sad at best but you are who you are.

When I receive off-list comments from users who are afraid to ask  
questions because of the way in which you and others appear to  
respond to people in general who are less knowledgeable than you  
about your code or the code base in general, this only further  
substantiates my opinion that you should seek professional help and  
refrain from responding to any pleas for assistance because you don't  
and wont play nice with others.

Others have chimed in and made comments regarding your condescending  
attitude and behavior but you seem to relish in the arguments, my  
personal opinion of you as a sane and respectful party who has the  
best interest of the b43 project they claim to represent has sunk so  
low that it's not publicly possible to state it without violating  
some law.

If people didn't think you were so important to the project and had a  
replacement they would have dumped you years ago, they accept your  
antics because it's the trade-off they are willing to accept and many  
people from this list have made this comment to me, the difference  
is, I don't mind saying it publicly.

Because they are willing to accept it doesn't mean every person who  
comes into contact with you must and I certainly don't.

Do yourself a favor and let it go, it's not beneficial to the project  
to act in this manner and it is my observation that you really seem  
to have no common sense regarding your treatment towards others when  
you can make unfounded remarks about an individual as if it were  
factual.

I understand how people with power will abuse that power when ever  
someone questions their actions and attitudes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110204/4064abe1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 188 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110204/4064abe1/attachment-0001.sig>

From gavron at wetwork.net  Fri Feb  4 17:22:19 2011
From: gavron at wetwork.net (Ehud Gavron)
Date: Fri, 04 Feb 2011 15:22:19 -0700
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <4D27236F-1DEC-464C-836B-A8DD2B911D07@daleenterprise.com>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie>
	<20110203223430.18158.qmail@stuge.se>
	<1296773390.9535.13.camel@maggie>
	<20110203234730.28953.qmail@stuge.se>
	<1296779345.9535.46.camel@maggie>
	<C038DB15-6427-46CC-A730-1A39CE6B9317@daleenterprise.com>
	<AANLkTinwd78AvXH5qy3+q3Y+_WecX4dcfnQzY5wQ3JUn@mail.gmail.com>
	<20AF06EF-A5CC-4944-8C9D-26A451A37AE4@daleenterprise.com>
	<1296822097.19557.24.camel@maggie>
	<4D27236F-1DEC-464C-836B-A8DD2B911D07@daleenterprise.com>
Message-ID: <4D4C7C1B.7070202@wetwork.net>



On 02/04/2011 02:38 PM, Dale Walsh wrote:
> Be smart, let it go.
Great advice, Dale.  One day when Michael is a leech and a noncontributor I'm sure he'll listen to you.

Go take your own advice.

Now.

E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110204/5e632048/attachment.html>

From mb at bu3sch.de  Fri Feb  4 17:26:08 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Fri, 04 Feb 2011 23:26:08 +0100
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <4D27236F-1DEC-464C-836B-A8DD2B911D07@daleenterprise.com>
	(sfid-20110204_223828_364724_FFFFFFFFFE527574)
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie> <20110203223430.18158.qmail@stuge.se>
	<1296773390.9535.13.camel@maggie> <20110203234730.28953.qmail@stuge.se>
	<1296779345.9535.46.camel@maggie>
	<C038DB15-6427-46CC-A730-1A39CE6B9317@daleenterprise.com>
	<AANLkTinwd78AvXH5qy3+q3Y+_WecX4dcfnQzY5wQ3JUn@mail.gmail.com>
	<20AF06EF-A5CC-4944-8C9D-26A451A37AE4@daleenterprise.com>
	(sfid-20110204_070621_977672_615B1101)
	<1296822097.19557.24.camel@maggie>
	<4D27236F-1DEC-464C-836B-A8DD2B911D07@daleenterprise.com>
	(sfid-20110204_223828_364724_FFFFFFFFFE527574)
Message-ID: <1296858368.21503.27.camel@maggie>

On Fri, 2011-02-04 at 16:38 -0500, Dale Walsh wrote: 
> Be smart, let it go.


> Are you really that slow 

I'll leave it as an exercise to you to find all the
personal insults in this quote.

> If I put my car key in the ignition of my car, turn it and nothing
> happens I call the dealer because it's obviously broken.
> You most likely would interpret that statement to be only what is
> stated and have some smart-assed comment that implies I'm not smart
> enough to determine if there is an electrical issue such as a dead
> battery preventing the car from starting or I didn't turn the key far
> enough and I conclude this based on the way in which you respond not
> only to me but others.

You probably forgot to put gas into the car.

> --- START OF QUOTE ---
> On Feb 03, 2011, at 19:29 PM, Michael B?sch wrote:
> > That guy will brick his device anyway, as 
> > he _will_ write incorrect data to the SPROM. 
> --- END OF QUOTE ---

I fail to find the words "idiot" and "moron" in this quote.
q.e.d.

> I specifically state it is my personal decision regarding the state of
> the source tree, are you now accepting responsibility for the entire
> ubuntu source tree?

Why would I?
I am not an Ubuntu developer. Why would I have any responsibility for
a single line of code in their distribution?

Do you notice the flawed logics?

> If you want to be responsible for a public project that offers public
> support that's great but expect that issue will come up and people
> will expect support and this has nothing to do with the purpose for
> which they use the software, my opinion is this,  it's a public
> project which offers support and you seem to be the leader so, if it's
> broke, fix it, if it isn't broke attempt to help the user in a kind
> and courteous manner and if you can't be kind and courteous don't
> involve yourself in assisting them, they are already frustrated enough
> by the fact that the software doesn't work the way they expect it to
> that they don't need to be further aggravated by a person offering
> support.

So the situation is:
I put my free time into a project that probably helps people. And
you're essentially complaining that I don't put enough of my valuable
free time into the project? Who are you to judge where I'm supposed
to spend my free time? We are not your personal support army.
You got our code for free. For free as in beer and as in freedom.
Without any implied warranties. Deal with it.

You know what? If I knew you in real life and you bitched about
a birthday present I gave you, it would be the very last present you
got from me. 
> You really don't appear to have enough common sense to let things go
> and believe you have made no attacks on anyone at any time which is
> sad at best but you are who you are.

Uh, talking about common sense.
I'm deeply sorry that I personally attacked you with my C sourcecode.
Where am I supposed to send the gift hamper to?

> When I receive off-list comments from users who are afraid to ask
> questions because of the way in which you and others appear to respond
> to people in general who are less knowledgeable than you about your
> code or the code base in general,

You probably think that you're the only one getting supportive off-list
comments from people. Guess what? You're possibly wrong.

> this only further substantiates my opinion that you should seek
> professional help and refrain from responding to any pleas for
> assistance because you don't and wont play nice with others.

Oh, professional help. Here we go.

> Others have chimed in and made comments regarding your condescending
> attitude and behavior but you seem to relish in the arguments, my
> personal opinion of you as a sane and respectful party who has the
> best interest of the b43 project they claim to represent has sunk so
> low that it's not publicly possible to state it without violating some
> law.

Wow. I think that reveals more of your attitude than of mine.

> If people didn't think you were so important to the project and had a
> replacement they would have dumped you years ago, they accept your
> antics because it's the trade-off they are willing to accept and many
> people from this list have made this comment to me, the difference is,
> I don't mind saying it publicly.

If you had followed b43 development remotely, you would have noticed
that I'm certainly not an important person to the project. Larry,
Rafal and all those others working on LP and N support are way more
important to the project than me.
And that's fine.

> Do yourself a favor and let it go, it's not beneficial to the project
> to act in this manner and it is my observation that you really seem to
> have no common sense regarding your treatment towards others when you
> can make unfounded remarks about an individual as if it were factual.

You're pretty entertaining. And that's actually the only reason I reply
to your mails.


-- 
Greetings Michael.



From zajec5 at gmail.com  Fri Feb  4 17:29:56 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Fri, 4 Feb 2011 23:29:56 +0100
Subject: unable to write flashrom, functionality broken?
In-Reply-To: <4D27236F-1DEC-464C-836B-A8DD2B911D07@daleenterprise.com>
References: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>
	<4D4834C0.5060701@lwfinger.net>
	<463A54B6-A0A4-4197-A19A-067FBDC63F66@daleenterprise.com>
	<4D4A208F.50408@lwfinger.net>
	<16F75F7A-922A-4472-96C8-2938F62EDBB8@daleenterprise.com>
	<1296734372.26739.21.camel@maggie>
	<BBF13C67-6DC8-4ED3-A4C2-13F6FB4F090A@daleenterprise.com>
	<1296770788.9535.1.camel@maggie>
	<20110203223430.18158.qmail@stuge.se>
	<1296773390.9535.13.camel@maggie>
	<20110203234730.28953.qmail@stuge.se>
	<1296779345.9535.46.camel@maggie>
	<C038DB15-6427-46CC-A730-1A39CE6B9317@daleenterprise.com>
	<AANLkTinwd78AvXH5qy3+q3Y+_WecX4dcfnQzY5wQ3JUn@mail.gmail.com>
	<20AF06EF-A5CC-4944-8C9D-26A451A37AE4@daleenterprise.com>
	<1296822097.19557.24.camel@maggie>
	<4D27236F-1DEC-464C-836B-A8DD2B911D07@daleenterprise.com>
Message-ID: <AANLkTim6dfFaT1_LOkdXkrCDRfxfEZCQu0YY7k5o3xgZ@mail.gmail.com>

2011/2/4 Dale Walsh <dale at daleenterprise.com>:
> Be smart, let it go.
>
> (...)
>
> If I put my car key in the ignition of my car, turn it and nothing happens I
> call the dealer because it's?obviously?broken.

Then call your dealer, not ignition producer. Find other ppl to troll
with, nobody here is interested.

Michael: you don great job for Linux, your replies are fine but we
have to agree there is no sense about that. Dale don't want to
understand/agree and he won't. I strongly suggest re-applying your
filter you got on old machine ;)

-- 
Rafa?


From mb at bu3sch.de  Fri Feb  4 17:34:45 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Fri, 04 Feb 2011 23:34:45 +0100
Subject: [PATCH] ssb-pcmcia: Fix parsing of invariants tuples
Message-ID: <1296858885.21503.33.camel@maggie>

This fixes parsing of the device invariants (MAC address)
for PCMCIA SSB devices.

ssb_pcmcia_do_get_invariants expects an iv pointer as data
argument.

Tested-by: dylan cristiani <d.cristiani at idem-tech.it>
Signed-off-by: Michael Buesch <mb at bu3sch.de>
Cc: stable at kernel.org

---


Index: wireless-testing/drivers/ssb/pcmcia.c
===================================================================
--- wireless-testing.orig/drivers/ssb/pcmcia.c	2010-12-30 15:49:39.000000000 +0100
+++ wireless-testing/drivers/ssb/pcmcia.c	2011-02-04 23:29:37.000000000 +0100
@@ -733,7 +733,7 @@ int ssb_pcmcia_get_invariants(struct ssb
 
 	/* Fetch the vendor specific tuples. */
 	res = pcmcia_loop_tuple(bus->host_pcmcia, SSB_PCMCIA_CIS,
-				ssb_pcmcia_do_get_invariants, sprom);
+				ssb_pcmcia_do_get_invariants, iv);
 	if ((res == 0) || (res == -ENOSPC))
 		return 0;
 

-- 
Greetings Michael.



From zajec5 at gmail.com  Fri Feb  4 17:55:18 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Fri, 4 Feb 2011 23:55:18 +0100
Subject: [PATCH] ssb-pcmcia: Fix parsing of invariants tuples
In-Reply-To: <1296858885.21503.33.camel@maggie>
References: <1296858885.21503.33.camel@maggie>
Message-ID: <AANLkTimo61j4K8MW7z5ssc=yjE=D--xX6oextej8q84q@mail.gmail.com>

2011/2/4 Michael B?sch <mb at bu3sch.de>:
> This fixes parsing of the device invariants (MAC address)
> for PCMCIA SSB devices.
>
> ssb_pcmcia_do_get_invariants expects an iv pointer as data
> argument.
>
> Tested-by: dylan cristiani <d.cristiani at idem-tech.it>
> Signed-off-by: Michael Buesch <mb at bu3sch.de>
> Cc: stable at kernel.org

For stable: it's regression in 2.6.33. AFAIU there is no need to apply
that for 2.6.32.

-- 
Rafa?


From Larry.Finger at lwfinger.net  Fri Feb  4 22:22:16 2011
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Fri, 04 Feb 2011 21:22:16 -0600
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>	<4D4C5595.7060903@lwfinger.net>
	<AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>
Message-ID: <4D4CC268.2080008@lwfinger.net>

On 02/04/2011 02:27 PM, Rafa? Mi?ecki wrote:
> W dniu 4 lutego 2011 20:37 u?ytkownik Larry Finger
> <Larry.Finger at lwfinger.net> napisa?:
>> On 02/04/2011 12:56 PM, Rafa? Mi?ecki wrote:
>>> I'd like to propose little (nothing big) reogranisation of b43 hardware table:
>>> http://wireless.kernel.org/Zajec?action=recall&rev=4
>>>
>>> Changed columns support/supported and driver/alternatives.
>>>
>>> Are you fine with that? Can we use colored one?
>>
>> I like the colored one.
>>
>> Some small changes:
>>
>> I would eliminate the second 14e4:4312 line and move the wl entry to the first
>> one. I don't know if wl supports 5 GHz on that chip. I don't have mine any longer.
> 
> Do you know anything about that duplicated ID? Is that true at all?
> Why we don't support device with that duplicated ID? Why do you want
> to remove it?

I'm not sure that there really is an 802.11b/g device with ID 14e4:4312. There
are two flavors of BCM4312, one that is 802.11a/b/g (14e4:4312), and an
802.11b/g device with ID 14e4:4315, which is the LP PHY. I suspect that the
confusion over the two BCM4312 items led to the duplicate entry in this table.

Larry
.


From netrolller.3d at gmail.com  Sat Feb  5 00:56:31 2011
From: netrolller.3d at gmail.com (=?ISO-8859-1?Q?G=E1bor_Stefanik?=)
Date: Sat, 5 Feb 2011 06:56:31 +0100
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <4D4CC268.2080008@lwfinger.net>
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	<4D4C5595.7060903@lwfinger.net>
	<AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>
	<4D4CC268.2080008@lwfinger.net>
Message-ID: <AANLkTinSVSx_AZ=sc+f5UF_8WRRtnotXZxOdXU4YOEB8@mail.gmail.com>

2011/2/5 Larry Finger <Larry.Finger at lwfinger.net>:
> On 02/04/2011 02:27 PM, Rafa? Mi?ecki wrote:
>> W dniu 4 lutego 2011 20:37 u?ytkownik Larry Finger
>> <Larry.Finger at lwfinger.net> napisa?:
>>> On 02/04/2011 12:56 PM, Rafa? Mi?ecki wrote:
>>>> I'd like to propose little (nothing big) reogranisation of b43 hardware table:
>>>> http://wireless.kernel.org/Zajec?action=recall&rev=4
>>>>
>>>> Changed columns support/supported and driver/alternatives.
>>>>
>>>> Are you fine with that? Can we use colored one?
>>>
>>> I like the colored one.
>>>
>>> Some small changes:
>>>
>>> I would eliminate the second 14e4:4312 line and move the wl entry to the first
>>> one. I don't know if wl supports 5 GHz on that chip. I don't have mine any longer.
>>
>> Do you know anything about that duplicated ID? Is that true at all?
>> Why we don't support device with that duplicated ID? Why do you want
>> to remove it?
>
> I'm not sure that there really is an 802.11b/g device with ID 14e4:4312. There
> are two flavors of BCM4312, one that is 802.11a/b/g (14e4:4312), and an
> 802.11b/g device with ID 14e4:4315, which is the LP PHY. I suspect that the
> confusion over the two BCM4312 items led to the duplicate entry in this table.

The device with PCI ID 0x4312 is called BCM4311 (dual-band) - check
Broadcom's official brochure on BCM4311 (has a single-band and a
dual-band version). Same for 0x4319 - it's actually BCM4318 dual-band
(for example, the BCM94318MPAGH has this ID). The only BCM4312 is
0x4315 (also, there exists no "BCM4315", and while BCM4310 might
indeed be real, it has nothing to do with PCI ID 0x4315). Apparently
the correlation between PCI ID and chip ID only exists for pure G-PHY
cards.

>
> Larry
> .
>
> _______________________________________________
> b43-dev mailing list
> b43-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/b43-dev
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)


From mb at bu3sch.de  Sat Feb  5 05:06:48 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Sat, 05 Feb 2011 11:06:48 +0100
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <AANLkTinSVSx_AZ=sc+f5UF_8WRRtnotXZxOdXU4YOEB8@mail.gmail.com>
	(sfid-20110205_005653_878895_D8DCA330)
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	<4D4C5595.7060903@lwfinger.net>
	<AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>
	<4D4CC268.2080008@lwfinger.net>
	<AANLkTinSVSx_AZ=sc+f5UF_8WRRtnotXZxOdXU4YOEB8@mail.gmail.com>
	(sfid-20110205_005653_878895_D8DCA330)
Message-ID: <1296900408.21503.34.camel@maggie>

On Sat, 2011-02-05 at 06:56 +0100, G?bor Stefanik wrote: 
> Apparently
> the correlation between PCI ID and chip ID only exists for pure G-PHY
> cards.

It doesn't exist at all.

-- 
Greetings Michael.



From jonas.gorski at gmail.com  Sat Feb  5 06:39:41 2011
From: jonas.gorski at gmail.com (Jonas Gorski)
Date: Sat, 5 Feb 2011 12:39:41 +0100
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <AANLkTinSVSx_AZ=sc+f5UF_8WRRtnotXZxOdXU4YOEB8@mail.gmail.com>
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	<4D4C5595.7060903@lwfinger.net>
	<AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>
	<4D4CC268.2080008@lwfinger.net>
	<AANLkTinSVSx_AZ=sc+f5UF_8WRRtnotXZxOdXU4YOEB8@mail.gmail.com>
Message-ID: <AANLkTi=ug=bqcegmE4an1zQCCHFFjtNJ7DxYSey6vkXx@mail.gmail.com>

2011/2/5 G?bor Stefanik <netrolller.3d at gmail.com>:
> The device with PCI ID 0x4312 is called BCM4311 (dual-band) - check
> Broadcom's official brochure on BCM4311 (has a single-band and a
> dual-band version). Same for 0x4319 - it's actually BCM4318 dual-band
> (for example, the BCM94318MPAGH has this ID). The only BCM4312 is
> 0x4315 (also, there exists no "BCM4315", and while BCM4310 might
> indeed be real, it has nothing to do with PCI ID 0x4315). Apparently
> the correlation between PCI ID and chip ID only exists for pure G-PHY
> cards.

A look into a recent bcmdevs.h agrees with this. But the correlation
seems to be true for only a few devices, and one is a dualband chip
(the 43421):

/* PCI Device ID's */
#define BCM4210_DEVICE_ID       0x1072          /* never used */
#define BCM4230_DEVICE_ID       0x1086          /* never used */
#define BCM4401_ENET_ID         0x170c          /* 4401b0 production
enet cards */
#define BCM3352_DEVICE_ID       0x3352          /* bcm3352 device id */
#define BCM3360_DEVICE_ID       0x3360          /* bcm3360 device id */
#define BCM4211_DEVICE_ID       0x4211
#define BCM4231_DEVICE_ID       0x4231
#define BCM4303_D11B_ID         0x4303          /* 4303 802.11b */
#define BCM4311_D11G_ID         0x4311          /* 4311 802.11b/g id */
#define BCM4311_D11DUAL_ID      0x4312          /* 4311 802.11a/b/g id */
#define BCM4311_D11A_ID         0x4313          /* 4311 802.11a id */
#define BCM4328_D11DUAL_ID      0x4314          /* 4328/4312 802.11a/g id */
#define BCM4328_D11G_ID         0x4315          /* 4328/4312 802.11g id */
#define BCM4328_D11A_ID         0x4316          /* 4328/4312 802.11a id */
#define BCM4318_D11G_ID         0x4318          /* 4318 802.11b/g id */
#define BCM4318_D11DUAL_ID      0x4319          /* 4318 802.11a/b/g id */
#define BCM4318_D11A_ID         0x431a          /* 4318 802.11a id */
#define BCM4325_D11DUAL_ID      0x431b          /* 4325 802.11a/g id */
#define BCM4325_D11G_ID         0x431c          /* 4325 802.11g id */
#define BCM4325_D11A_ID         0x431d          /* 4325 802.11a id */
#define BCM4306_D11G_ID         0x4320          /* 4306 802.11g */
#define BCM4306_D11A_ID         0x4321          /* 4306 802.11a */
#define BCM4306_UART_ID         0x4322          /* 4306 uart */
#define BCM4306_V90_ID          0x4323          /* 4306 v90 codec */
#define BCM4306_D11DUAL_ID      0x4324          /* 4306 dual A+B */
#define BCM4306_D11G_ID2        0x4325          /* BCM4306_D11G_ID;
INF w/loose binding war */
#define BCM4321_D11N_ID         0x4328          /* 4321 802.11n dualband id */
#define BCM4321_D11N2G_ID       0x4329          /* 4321 802.11n 2.4Ghz
band id */
#define BCM4321_D11N5G_ID       0x432a          /* 4321 802.11n 5Ghz band id */
#define BCM4322_D11N_ID         0x432b          /* 4322 802.11n
dualband device */
#define BCM4322_D11N2G_ID       0x432c          /* 4322 802.11n 2.4GHz device */
#define BCM4322_D11N5G_ID       0x432d          /* 4322 802.11n 5GHz device */
#define BCM43221_D11N2G_ID      0x4341          /* 43221 802.11n
2.4GHz device */
#define BCM43231_D11N2G_ID      0x4340          /* 43231 802.11n
2.4GHz device */
#define BCM43222_D11N_ID        0x4350          /* 43222 802.11n
dualband device */
#define BCM43222_D11N2G_ID      0x4351          /* 43222 802.11n
2.4GHz device */
#define BCM43222_D11N5G_ID      0x4352          /* 43222 802.11n 5GHz device */
#define BCM43224_D11N_ID        0x4353          /* 43224 802.11n
dualband device */
#define BCM43225_D11N2G_ID      0x4357          /* 43225 802.11n
2.4GHz device */
#define BCM43421_D11N_ID        0xA99D          /* 43421 802.11n
dualband device */
#define BCM4315_D11DUAL_ID      0x4334          /* 4315 802.11a/g id */
#define BCM4315_D11G_ID         0x4335          /* 4315 802.11g id */
#define BCM4315_D11A_ID         0x4336          /* 4315 802.11a id */


It doesn't seem to be complete though; I have a 2G BCM4322 on
a BCM6358 board that uses the PCI ID 14e4:4322.

-- 
Regards,
Jonas


From zajec5 at gmail.com  Sat Feb  5 08:35:07 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Sat, 5 Feb 2011 14:35:07 +0100
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <4D4CC268.2080008@lwfinger.net>
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	<4D4C5595.7060903@lwfinger.net>
	<AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>
	<4D4CC268.2080008@lwfinger.net>
Message-ID: <AANLkTimdK0QqHYCav2T=XMhn-77QE0dkbhxtbbxrgz8K@mail.gmail.com>

W dniu 5 lutego 2011 04:22 u?ytkownik Larry Finger
<Larry.Finger at lwfinger.net> napisa?:
> On 02/04/2011 02:27 PM, Rafa? Mi?ecki wrote:
>> W dniu 4 lutego 2011 20:37 u?ytkownik Larry Finger
>> <Larry.Finger at lwfinger.net> napisa?:
>>> On 02/04/2011 12:56 PM, Rafa? Mi?ecki wrote:
>>>> I'd like to propose little (nothing big) reogranisation of b43 hardware table:
>>>> http://wireless.kernel.org/Zajec?action=recall&rev=4
>>>>
>>>> Changed columns support/supported and driver/alternatives.
>>>>
>>>> Are you fine with that? Can we use colored one?
>>>
>>> I like the colored one.
>>>
>>> Some small changes:
>>>
>>> I would eliminate the second 14e4:4312 line and move the wl entry to the first
>>> one. I don't know if wl supports 5 GHz on that chip. I don't have mine any longer.
>>
>> Do you know anything about that duplicated ID? Is that true at all?
>> Why we don't support device with that duplicated ID? Why do you want
>> to remove it?
>
> I'm not sure that there really is an 802.11b/g device with ID 14e4:4312. There
> are two flavors of BCM4312, one that is 802.11a/b/g (14e4:4312), and an
> 802.11b/g device with ID 14e4:4315, which is the LP PHY. I suspect that the
> confusion over the two BCM4312 items led to the duplicate entry in this table.

Hm, it was actually you who added that entry:
http://wireless.kernel.org/en/users/Drivers/b43?action=diff&rev1=135&rev2=136
http://wireless.kernel.org/en/users/Drivers/b43?action=diff&rev1=136&rev2=137

-- 
Rafa?


From zajec5 at gmail.com  Sat Feb  5 08:38:37 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Sat, 5 Feb 2011 14:38:37 +0100
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <AANLkTi=ug=bqcegmE4an1zQCCHFFjtNJ7DxYSey6vkXx@mail.gmail.com>
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	<4D4C5595.7060903@lwfinger.net>
	<AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>
	<4D4CC268.2080008@lwfinger.net>
	<AANLkTinSVSx_AZ=sc+f5UF_8WRRtnotXZxOdXU4YOEB8@mail.gmail.com>
	<AANLkTi=ug=bqcegmE4an1zQCCHFFjtNJ7DxYSey6vkXx@mail.gmail.com>
Message-ID: <AANLkTi=HkUpDgMU+dOOMffqs=u9fMi-vM-KT=6-1Xg=j@mail.gmail.com>

2011/2/5 Jonas Gorski <jonas.gorski at gmail.com>:
> It doesn't seem to be complete though; I have a 2G BCM4322 on
> a BCM6358 board that uses the PCI ID 14e4:4322.

Can you double check that your 14e4:4322 is BCM4322, check it's PHY
version (plus revision) and add entry for it in table:
http://wireless.kernel.org/en/users/Drivers/b43
?

-- 
Rafa?


From Larry.Finger at lwfinger.net  Sat Feb  5 10:56:44 2011
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Sat, 05 Feb 2011 09:56:44 -0600
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <AANLkTinSVSx_AZ=sc+f5UF_8WRRtnotXZxOdXU4YOEB8@mail.gmail.com>
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	<4D4C5595.7060903@lwfinger.net>
	<AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>
	<4D4CC268.2080008@lwfinger.net>
	<AANLkTinSVSx_AZ=sc+f5UF_8WRRtnotXZxOdXU4YOEB8@mail.gmail.com>
Message-ID: <4D4D733C.30906@lwfinger.net>

On 02/04/2011 11:56 PM, G?bor Stefanik wrote:
> 2011/2/5 Larry Finger <Larry.Finger at lwfinger.net>:
>> On 02/04/2011 02:27 PM, Rafa? Mi?ecki wrote:
>>> W dniu 4 lutego 2011 20:37 u?ytkownik Larry Finger
>>> <Larry.Finger at lwfinger.net> napisa?:
>>>> On 02/04/2011 12:56 PM, Rafa? Mi?ecki wrote:
>>>>> I'd like to propose little (nothing big) reogranisation of b43 hardware table:
>>>>> http://wireless.kernel.org/Zajec?action=recall&rev=4
>>>>>
>>>>> Changed columns support/supported and driver/alternatives.
>>>>>
>>>>> Are you fine with that? Can we use colored one?
>>>>
>>>> I like the colored one.
>>>>
>>>> Some small changes:
>>>>
>>>> I would eliminate the second 14e4:4312 line and move the wl entry to the first
>>>> one. I don't know if wl supports 5 GHz on that chip. I don't have mine any longer.
>>>
>>> Do you know anything about that duplicated ID? Is that true at all?
>>> Why we don't support device with that duplicated ID? Why do you want
>>> to remove it?
>>
>> I'm not sure that there really is an 802.11b/g device with ID 14e4:4312. There
>> are two flavors of BCM4312, one that is 802.11a/b/g (14e4:4312), and an
>> 802.11b/g device with ID 14e4:4315, which is the LP PHY. I suspect that the
>> confusion over the two BCM4312 items led to the duplicate entry in this table.
> 
> The device with PCI ID 0x4312 is called BCM4311 (dual-band) - check
> Broadcom's official brochure on BCM4311 (has a single-band and a
> dual-band version). Same for 0x4319 - it's actually BCM4318 dual-band
> (for example, the BCM94318MPAGH has this ID). The only BCM4312 is
> 0x4315 (also, there exists no "BCM4315", and while BCM4310 might
> indeed be real, it has nothing to do with PCI ID 0x4315). Apparently
> the correlation between PCI ID and chip ID only exists for pure G-PHY
> cards.
>
Check Comment #6 in the thread at
http://forums.opensuse.org/forums/english/get-technical-help-here/wireless/453614-wireless-card-dormant-until-wired-connection-detected.html.
A BCM4312 with ID 14e4:4312.

Larry


From jonas.gorski at gmail.com  Sat Feb  5 11:13:22 2011
From: jonas.gorski at gmail.com (Jonas Gorski)
Date: Sat, 5 Feb 2011 17:13:22 +0100
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <AANLkTi=HkUpDgMU+dOOMffqs=u9fMi-vM-KT=6-1Xg=j@mail.gmail.com>
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	<4D4C5595.7060903@lwfinger.net>
	<AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>
	<4D4CC268.2080008@lwfinger.net>
	<AANLkTinSVSx_AZ=sc+f5UF_8WRRtnotXZxOdXU4YOEB8@mail.gmail.com>
	<AANLkTi=ug=bqcegmE4an1zQCCHFFjtNJ7DxYSey6vkXx@mail.gmail.com>
	<AANLkTi=HkUpDgMU+dOOMffqs=u9fMi-vM-KT=6-1Xg=j@mail.gmail.com>
Message-ID: <AANLkTi=XH=tmzVCR_xMUPoVqbdcwCBp6wvZ2sUpHC7UH@mail.gmail.com>

On 5 February 2011 14:38, Rafa? Mi?ecki <zajec5 at gmail.com> wrote:
> Can you double check that your 14e4:4322 is BCM4322, check it's PHY
> version (plus revision)

The proprietary broadcom driver identifies it as a BCM4322, as does b43:

b43-phy0: Broadcom 4322 WLAN found (core revision 16)
b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 8, Type 4, Revision 4)

> and add entry for it in table:
> http://wireless.kernel.org/en/users/Drivers/b43
> ?

Will do. I assume the r<number> means the PHY revision?

-- 
Regards,
Jonas


From Larry.Finger at lwfinger.net  Sat Feb  5 11:24:31 2011
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Sat, 05 Feb 2011 10:24:31 -0600
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <AANLkTi=XH=tmzVCR_xMUPoVqbdcwCBp6wvZ2sUpHC7UH@mail.gmail.com>
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	<4D4C5595.7060903@lwfinger.net>
	<AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>
	<4D4CC268.2080008@lwfinger.net>
	<AANLkTinSVSx_AZ=sc+f5UF_8WRRtnotXZxOdXU4YOEB8@mail.gmail.com>
	<AANLkTi=ug=bqcegmE4an1zQCCHFFjtNJ7DxYSey6vkXx@mail.gmail.com>
	<AANLkTi=HkUpDgMU+dOOMffqs=u9fMi-vM-KT=6-1Xg=j@mail.gmail.com>
	<AANLkTi=XH=tmzVCR_xMUPoVqbdcwCBp6wvZ2sUpHC7UH@mail.gmail.com>
Message-ID: <4D4D79BF.9030707@lwfinger.net>

On 02/05/2011 10:13 AM, Jonas Gorski wrote:
> On 5 February 2011 14:38, Rafa? Mi?ecki <zajec5 at gmail.com> wrote:
>> Can you double check that your 14e4:4322 is BCM4322, check it's PHY
>> version (plus revision)
> 
> The proprietary broadcom driver identifies it as a BCM4322, as does b43:
> 
> b43-phy0: Broadcom 4322 WLAN found (core revision 16)
> b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 8, Type 4, Revision 4)
> 
>> and add entry for it in table:
>> http://wireless.kernel.org/en/users/Drivers/b43
>> ?
> 
> Will do. I assume the r<number> means the PHY revision?

Please recheck the PCI ID for this one. That Revision 4 N PHY (type 4) with a
Revision 16 802.11 core looks to be the same as my device with ID 14e4:432b.

Larry


From jonas.gorski at gmail.com  Sat Feb  5 11:38:58 2011
From: jonas.gorski at gmail.com (Jonas Gorski)
Date: Sat, 5 Feb 2011 17:38:58 +0100
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <4D4D79BF.9030707@lwfinger.net>
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	<4D4C5595.7060903@lwfinger.net>
	<AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>
	<4D4CC268.2080008@lwfinger.net>
	<AANLkTinSVSx_AZ=sc+f5UF_8WRRtnotXZxOdXU4YOEB8@mail.gmail.com>
	<AANLkTi=ug=bqcegmE4an1zQCCHFFjtNJ7DxYSey6vkXx@mail.gmail.com>
	<AANLkTi=HkUpDgMU+dOOMffqs=u9fMi-vM-KT=6-1Xg=j@mail.gmail.com>
	<AANLkTi=XH=tmzVCR_xMUPoVqbdcwCBp6wvZ2sUpHC7UH@mail.gmail.com>
	<4D4D79BF.9030707@lwfinger.net>
Message-ID: <AANLkTik_9O0U+YaALdqDr5YyBy9UzrMp+9UW5TRtz+xw@mail.gmail.com>

2011/2/5 Larry Finger <Larry.Finger at lwfinger.net>:
> Please recheck the PCI ID for this one. That Revision 4 N PHY (type 4) with a
> Revision 16 802.11 core looks to be the same as my device with ID 14e4:432b.

root at OpenWrt:~# lspci -vnn
00:01.0 Network controller [0280]: Broadcom Corporation BCM4306 UART
[14e4:4322] (rev 01)
        Subsystem: Broadcom Corporation BCM4306 UART [14e4:4322]
        Flags: bus master, fast devsel, latency 64, IRQ 39
        Memory at 30000000 (32-bit, non-prefetchable) [size=16K]
        Kernel driver in use: b43-pci-bridge

-- 
Regards,
Jonas


From zajec5 at gmail.com  Sat Feb  5 12:24:09 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Sat, 5 Feb 2011 18:24:09 +0100
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <AANLkTi=XH=tmzVCR_xMUPoVqbdcwCBp6wvZ2sUpHC7UH@mail.gmail.com>
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	<4D4C5595.7060903@lwfinger.net>
	<AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>
	<4D4CC268.2080008@lwfinger.net>
	<AANLkTinSVSx_AZ=sc+f5UF_8WRRtnotXZxOdXU4YOEB8@mail.gmail.com>
	<AANLkTi=ug=bqcegmE4an1zQCCHFFjtNJ7DxYSey6vkXx@mail.gmail.com>
	<AANLkTi=HkUpDgMU+dOOMffqs=u9fMi-vM-KT=6-1Xg=j@mail.gmail.com>
	<AANLkTi=XH=tmzVCR_xMUPoVqbdcwCBp6wvZ2sUpHC7UH@mail.gmail.com>
Message-ID: <AANLkTi=a5qZnk00A6CdTF+R+W505pNskHhm1nH7BRem6@mail.gmail.com>

2011/2/5 Jonas Gorski <jonas.gorski at gmail.com>:
> On 5 February 2011 14:38, Rafa? Mi?ecki <zajec5 at gmail.com> wrote:
>> Can you double check that your 14e4:4322 is BCM4322, check it's PHY
>> version (plus revision)
>
> The proprietary broadcom driver identifies it as a BCM4322, as does b43:
>
> b43-phy0: Broadcom 4322 WLAN found (core revision 16)
> b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 8, Type 4, Revision 4)
>
>> and add entry for it in table:
>> http://wireless.kernel.org/en/users/Drivers/b43
>> ?
>
> Will do. I assume the r<number> means the PHY revision?

Yes.

-- 
Rafa?


From zajec5 at gmail.com  Sat Feb  5 12:35:38 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Sat, 5 Feb 2011 18:35:38 +0100
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <4D4D733C.30906@lwfinger.net>
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	<4D4C5595.7060903@lwfinger.net>
	<AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>
	<4D4CC268.2080008@lwfinger.net>
	<AANLkTinSVSx_AZ=sc+f5UF_8WRRtnotXZxOdXU4YOEB8@mail.gmail.com>
	<4D4D733C.30906@lwfinger.net>
Message-ID: <AANLkTi=7mQw4xn4MrSo2FXzxM38XhxHxDoV-ESDm6OQe@mail.gmail.com>

W dniu 5 lutego 2011 16:56 u?ytkownik Larry Finger
<Larry.Finger at lwfinger.net> napisa?:
> On 02/04/2011 11:56 PM, G?bor Stefanik wrote:
>> 2011/2/5 Larry Finger <Larry.Finger at lwfinger.net>:
>>> On 02/04/2011 02:27 PM, Rafa? Mi?ecki wrote:
>>>> W dniu 4 lutego 2011 20:37 u?ytkownik Larry Finger
>>>> <Larry.Finger at lwfinger.net> napisa?:
>>>>> On 02/04/2011 12:56 PM, Rafa? Mi?ecki wrote:
>>>>>> I'd like to propose little (nothing big) reogranisation of b43 hardware table:
>>>>>> http://wireless.kernel.org/Zajec?action=recall&rev=4
>>>>>>
>>>>>> Changed columns support/supported and driver/alternatives.
>>>>>>
>>>>>> Are you fine with that? Can we use colored one?
>>>>>
>>>>> I like the colored one.
>>>>>
>>>>> Some small changes:
>>>>>
>>>>> I would eliminate the second 14e4:4312 line and move the wl entry to the first
>>>>> one. I don't know if wl supports 5 GHz on that chip. I don't have mine any longer.
>>>>
>>>> Do you know anything about that duplicated ID? Is that true at all?
>>>> Why we don't support device with that duplicated ID? Why do you want
>>>> to remove it?
>>>
>>> I'm not sure that there really is an 802.11b/g device with ID 14e4:4312. There
>>> are two flavors of BCM4312, one that is 802.11a/b/g (14e4:4312), and an
>>> 802.11b/g device with ID 14e4:4315, which is the LP PHY. I suspect that the
>>> confusion over the two BCM4312 items led to the duplicate entry in this table.
>>
>> The device with PCI ID 0x4312 is called BCM4311 (dual-band) - check
>> Broadcom's official brochure on BCM4311 (has a single-band and a
>> dual-band version). Same for 0x4319 - it's actually BCM4318 dual-band
>> (for example, the BCM94318MPAGH has this ID). The only BCM4312 is
>> 0x4315 (also, there exists no "BCM4315", and while BCM4310 might
>> indeed be real, it has nothing to do with PCI ID 0x4315). Apparently
>> the correlation between PCI ID and chip ID only exists for pure G-PHY
>> cards.
>>
> Check Comment #6 in the thread at
> http://forums.opensuse.org/forums/english/get-technical-help-here/wireless/453614-wireless-card-dormant-until-wired-connection-detected.html.
> A BCM4312 with ID 14e4:4312.

It's like from PCI database. Please check comment #17:
[  281.996359] b43-phy0: Broadcom 4311 WLAN found (core revision 10)
[  282.544261] Registered led device: b43-phy0::tx
[  282.544338] Registered led device: b43-phy0::rx
[  282.544390] Registered led device: b43-phy0::radio
[  283.943092] b43 ssb0:0: firmware: requesting b43/ucode5.fw
[  284.106390] b43 ssb0:0: firmware: requesting b43/pcm5.fw
[  284.120338] b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
[  284.195838] b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw

This 14e4:4312 is BCM4311 according to our logs and driver loads
b0g0initvals5, so it is G-PHY.

-- 
Rafa?


From zajec5 at gmail.com  Sat Feb  5 12:49:44 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Sat, 5 Feb 2011 18:49:44 +0100
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <AANLkTi=7mQw4xn4MrSo2FXzxM38XhxHxDoV-ESDm6OQe@mail.gmail.com>
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	<4D4C5595.7060903@lwfinger.net>
	<AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>
	<4D4CC268.2080008@lwfinger.net>
	<AANLkTinSVSx_AZ=sc+f5UF_8WRRtnotXZxOdXU4YOEB8@mail.gmail.com>
	<4D4D733C.30906@lwfinger.net>
	<AANLkTi=7mQw4xn4MrSo2FXzxM38XhxHxDoV-ESDm6OQe@mail.gmail.com>
Message-ID: <AANLkTi=V8pHfAzvqFsUMXHhmjVgfOYDTW0ipO+68aF-8@mail.gmail.com>

W dniu 5 lutego 2011 18:35 u?ytkownik Rafa? Mi?ecki <zajec5 at gmail.com> napisa?:
> W dniu 5 lutego 2011 16:56 u?ytkownik Larry Finger
> <Larry.Finger at lwfinger.net> napisa?:
>> On 02/04/2011 11:56 PM, G?bor Stefanik wrote:
>>> 2011/2/5 Larry Finger <Larry.Finger at lwfinger.net>:
>>>> On 02/04/2011 02:27 PM, Rafa? Mi?ecki wrote:
>>>>> W dniu 4 lutego 2011 20:37 u?ytkownik Larry Finger
>>>>> <Larry.Finger at lwfinger.net> napisa?:
>>>>>> On 02/04/2011 12:56 PM, Rafa? Mi?ecki wrote:
>>>>>>> I'd like to propose little (nothing big) reogranisation of b43 hardware table:
>>>>>>> http://wireless.kernel.org/Zajec?action=recall&rev=4
>>>>>>>
>>>>>>> Changed columns support/supported and driver/alternatives.
>>>>>>>
>>>>>>> Are you fine with that? Can we use colored one?
>>>>>>
>>>>>> I like the colored one.
>>>>>>
>>>>>> Some small changes:
>>>>>>
>>>>>> I would eliminate the second 14e4:4312 line and move the wl entry to the first
>>>>>> one. I don't know if wl supports 5 GHz on that chip. I don't have mine any longer.
>>>>>
>>>>> Do you know anything about that duplicated ID? Is that true at all?
>>>>> Why we don't support device with that duplicated ID? Why do you want
>>>>> to remove it?
>>>>
>>>> I'm not sure that there really is an 802.11b/g device with ID 14e4:4312. There
>>>> are two flavors of BCM4312, one that is 802.11a/b/g (14e4:4312), and an
>>>> 802.11b/g device with ID 14e4:4315, which is the LP PHY. I suspect that the
>>>> confusion over the two BCM4312 items led to the duplicate entry in this table.
>>>
>>> The device with PCI ID 0x4312 is called BCM4311 (dual-band) - check
>>> Broadcom's official brochure on BCM4311 (has a single-band and a
>>> dual-band version). Same for 0x4319 - it's actually BCM4318 dual-band
>>> (for example, the BCM94318MPAGH has this ID). The only BCM4312 is
>>> 0x4315 (also, there exists no "BCM4315", and while BCM4310 might
>>> indeed be real, it has nothing to do with PCI ID 0x4315). Apparently
>>> the correlation between PCI ID and chip ID only exists for pure G-PHY
>>> cards.
>>>
>> Check Comment #6 in the thread at
>> http://forums.opensuse.org/forums/english/get-technical-help-here/wireless/453614-wireless-card-dormant-until-wired-connection-detected.html.
>> A BCM4312 with ID 14e4:4312.
>
> It's like from PCI database. Please check comment #17:

I meant "lie" of course. I also Googled for:
"14e4:4312" "Broadcom 4312 wlan found"
and then for:
"14e4:4312" "Broadcom 4311 wlan found"
the first one won't give you any real, non-false, results.

According to http://pci-ids.ucw.cz/read/PC/14e4/4312 john.s.gustafsson
submitted name for this PCI ID containing "BCM4312". He probably
though PCI ID is in direct relation with Broadcom chipset used on
card.

john.s.gustafsson referred to link:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-March/004312.html
that does not work. I searched mails from March 2007, but didn't find
anything related.

We really need to treat this as mistake and fix table and pci database.

-- 
Rafa?


From zajec5 at gmail.com  Sat Feb  5 13:31:29 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Sat, 5 Feb 2011 19:31:29 +0100
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <AANLkTi=V8pHfAzvqFsUMXHhmjVgfOYDTW0ipO+68aF-8@mail.gmail.com>
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	<4D4C5595.7060903@lwfinger.net>
	<AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>
	<4D4CC268.2080008@lwfinger.net>
	<AANLkTinSVSx_AZ=sc+f5UF_8WRRtnotXZxOdXU4YOEB8@mail.gmail.com>
	<4D4D733C.30906@lwfinger.net>
	<AANLkTi=7mQw4xn4MrSo2FXzxM38XhxHxDoV-ESDm6OQe@mail.gmail.com>
	<AANLkTi=V8pHfAzvqFsUMXHhmjVgfOYDTW0ipO+68aF-8@mail.gmail.com>
Message-ID: <AANLkTinkx8s+8Xq19sKkHAhx_i7fr+ajOhHnKpxMFMto@mail.gmail.com>

W dniu 5 lutego 2011 18:49 u?ytkownik Rafa? Mi?ecki <zajec5 at gmail.com> napisa?:
> According to http://pci-ids.ucw.cz/read/PC/14e4/4312 john.s.gustafsson
> submitted name for this PCI ID containing "BCM4312". He probably
> though PCI ID is in direct relation with Broadcom chipset used on
> card.
>
> john.s.gustafsson referred to link:
> https://lists.berlios.de/pipermail/bcm43xx-dev/2007-March/004312.html
> that does not work. I searched mails from March 2007, but didn't find
> anything related.
>
> We really need to treat this as mistake and fix table and pci database.

I've submitted "fix" to database as discussion at:
https://pci-ids.ucw.cz/read/PC/14e4/4312?action=list

Is that correct way of doing that? This site seems a little... weird.

-- 
Rafa?


From zajec5 at gmail.com  Sat Feb  5 17:32:56 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Sat, 5 Feb 2011 23:32:56 +0100
Subject: Table of PCIs, chipsets, etc. on b43 wiki page
In-Reply-To: <AANLkTinkx8s+8Xq19sKkHAhx_i7fr+ajOhHnKpxMFMto@mail.gmail.com>
References: <AANLkTimPBdmiOQ=+TRzEGK4N8yZwj071b_pVkQzmw0RW@mail.gmail.com>
	<4D4C5595.7060903@lwfinger.net>
	<AANLkTi=QUEYGSnatgc6vfpOht0K3FzYRE38WgrAWbb8N@mail.gmail.com>
	<4D4CC268.2080008@lwfinger.net>
	<AANLkTinSVSx_AZ=sc+f5UF_8WRRtnotXZxOdXU4YOEB8@mail.gmail.com>
	<4D4D733C.30906@lwfinger.net>
	<AANLkTi=7mQw4xn4MrSo2FXzxM38XhxHxDoV-ESDm6OQe@mail.gmail.com>
	<AANLkTi=V8pHfAzvqFsUMXHhmjVgfOYDTW0ipO+68aF-8@mail.gmail.com>
	<AANLkTinkx8s+8Xq19sKkHAhx_i7fr+ajOhHnKpxMFMto@mail.gmail.com>
Message-ID: <AANLkTimBY06369wHtEMiQDPRNV=w-wx8yRYwOA0hO1uY@mail.gmail.com>

W dniu 5 lutego 2011 19:31 u?ytkownik Rafa? Mi?ecki <zajec5 at gmail.com> napisa?:
> W dniu 5 lutego 2011 18:49 u?ytkownik Rafa? Mi?ecki <zajec5 at gmail.com> napisa?:
>> According to http://pci-ids.ucw.cz/read/PC/14e4/4312 john.s.gustafsson
>> submitted name for this PCI ID containing "BCM4312". He probably
>> though PCI ID is in direct relation with Broadcom chipset used on
>> card.
>>
>> john.s.gustafsson referred to link:
>> https://lists.berlios.de/pipermail/bcm43xx-dev/2007-March/004312.html
>> that does not work. I searched mails from March 2007, but didn't find
>> anything related.
>>
>> We really need to treat this as mistake and fix table and pci database.
>
> I've submitted "fix" to database as discussion at:
> https://pci-ids.ucw.cz/read/PC/14e4/4312?action=list
>
> Is that correct way of doing that? This site seems a little... weird.

I've received mail about approving my change. Big confusion finally
explained and corrected :)

-- 
Rafa?


From h2o-post at gmx.net  Tue Feb  8 05:36:48 2011
From: h2o-post at gmx.net (h2o-post)
Date: Tue, 8 Feb 2011 11:36:48 +0100
Subject: 802.11 MAC state information
Message-ID: <009801cbc77c$17225830$45670890$@gmx.net>

Hi all,

I would like to know from the Broadcom experts, if there is the possibility in the b43 driver to read the current state of the 802.11 MAC..
As I am more familiar with the Atheros design, I am uncertain if there are register that someone could just sample to get this information or if you need to get some hocks int the micro controller code ??? 
To explain briefly the way I get this information form Atheros hardware: on the wifi card there is a 40MHzmac clock that counts up 4 registers. One for the clock ticks itself, one for the MAC been in transmitting mode, one counter for the MAC been in receiving mode and the last counter represents energy detection above the cca threshold.
I already checked the b43 souce code in order to find some registers that could count those mac states .. but I was not able to find anything. So I am asking to the list 
where such information would be accessible from the Broadcom wifi hardware.

Thx for helping
Thomas



From mb at bu3sch.de  Tue Feb  8 09:27:43 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Tue, 08 Feb 2011 15:27:43 +0100
Subject: 802.11 MAC state information
In-Reply-To: <009801cbc77c$17225830$45670890$@gmx.net>
	(sfid-20110208_053652_042296_D74736C9)
References: <009801cbc77c$17225830$45670890$@gmx.net>
	(sfid-20110208_053652_042296_D74736C9)
Message-ID: <1297175263.29400.11.camel@maggie>

On Tue, 2011-02-08 at 11:36 +0100, h2o-post wrote: 
> Hi all,
> 
> I would like to know from the Broadcom experts, if there is the possibility in the b43 driver to read the current state of the 802.11 MAC..
> As I am more familiar with the Atheros design, I am uncertain if there are register that someone could just sample to get this information or if you need to get some hocks int the micro controller code ??? 
> To explain briefly the way I get this information form Atheros hardware: on the wifi card there is a 40MHzmac clock that counts up 4 registers. One for the clock ticks itself, one for the MAC been in transmitting mode, one counter for the MAC been in receiving mode and the last counter represents energy detection above the cca threshold.
> I already checked the b43 souce code in order to find some registers that could count those mac states .. but I was not able to find anything. So I am asking to the list 
> where such information would be accessible from the Broadcom wifi hardware.

You can get all information you want from
http://bcm-v4.sipsolutions.net/

There's no such thing as "the MAC state". There are
hundreds of registers related to various "MAC states". So you'll
have to be more specific on what you want to know.

-- 
Greetings Michael.



From h2o-post at gmx.net  Tue Feb  8 10:21:28 2011
From: h2o-post at gmx.net (h2o-post)
Date: Tue, 8 Feb 2011 16:21:28 +0100
Subject: AW: 802.11 MAC state information
In-Reply-To: <1297175263.29400.11.camel@maggie>
References: <009801cbc77c$17225830$45670890$@gmx.net>	
	(sfid-20110208_053652_042296_D74736C9)
	<1297175263.29400.11.camel@maggie>
Message-ID: <00dc01cbc7a3$dbcc0a10$93641e30$@gmx.net>

> > Hi all,
> >
> > I would like to know from the Broadcom experts, if there is the possibility in
> the b43 driver to read the current state of the 802.11 MAC..
> > As I am more familiar with the Atheros design, I am uncertain if there are
> register that someone could just sample to get this information or if you
> need to get some hocks int the micro controller code ???
> > To explain briefly the way I get this information form Atheros hardware: on
> the wifi card there is a 40MHzmac clock that counts up 4 registers. One for
> the clock ticks itself, one for the MAC been in transmitting mode, one
> counter for the MAC been in receiving mode and the last counter represents
> energy detection above the cca threshold.
> > I already checked the b43 souce code in order to find some registers
> > that could count those mac states .. but I was not able to find anything. So I
> am asking to the list where such information would be accessible from the
> Broadcom wifi hardware.
> 
> You can get all information you want from http://bcm-v4.sipsolutions.net/
> 
> There's no such thing as "the MAC state". There are hundreds of registers
> related to various "MAC states". So you'll have to be more specific on what
> you want to know.

I would like to sample if the Broadcom wifi card (MAC) is transmitting, receiving or idle over time.
Within the Atheros hardware there are register counters that count if one of the above - I call them - mac-state are present.
Which those measurements I am looking into airtime consumption of different packets for sending and receiving.
For example: 1500Byte udp packet causes the sender wifi card @54Mbit  to be busy by this transmission for 240 micro sec (what I measure in the Atheros hardware is a txcounter increase by ~9600 ticks @40MHz)... also quite interesting are the distributions of receiving states over time and cca channel sensing busy over time.
I have implemented I quite fast mechanism to read/dump the Atheros registers to a trace file in order to validate different upper layer traffic patterns/settings. I would like to extend this measurement to Broadcom hardware as well. 
For Atheros also the wprobe-utility from nbd,  a nice tool that make use out of this "mac-state" over time measurements, maybe you have heard about it ?

Does this make sense to you what I am interested in ?

Thomas

> --
> Greetings Michael.



From mb at bu3sch.de  Tue Feb  8 10:28:53 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Tue, 08 Feb 2011 16:28:53 +0100
Subject: AW: 802.11 MAC state information
In-Reply-To: <00dc01cbc7a3$dbcc0a10$93641e30$@gmx.net>
	(sfid-20110208_102132_361673_7C2434FF)
References: <009801cbc77c$17225830$45670890$@gmx.net>
	(sfid-20110208_053652_042296_D74736C9)
	<1297175263.29400.11.camel@maggie>
	<00dc01cbc7a3$dbcc0a10$93641e30$@gmx.net>
	(sfid-20110208_102132_361673_7C2434FF)
Message-ID: <1297178933.29400.16.camel@maggie>

On Tue, 2011-02-08 at 16:21 +0100, h2o-post wrote: 
> I would like to sample if the Broadcom wifi card (MAC) is transmitting, receiving or idle over time.
> Within the Atheros hardware there are register counters that count if one of the above - I call them - mac-state are present.
> Which those measurements I am looking into airtime consumption of different packets for sending and receiving.
> For example: 1500Byte udp packet causes the sender wifi card @54Mbit  to be busy by this transmission for 240 micro sec (what I measure in the Atheros hardware is a txcounter increase by ~9600 ticks @40MHz)... also quite interesting are the distributions of receiving states over time and cca channel sensing busy over time.
> I have implemented I quite fast mechanism to read/dump the Atheros registers to a trace file in order to validate different upper layer traffic patterns/settings. I would like to extend this measurement to Broadcom hardware as well. 
> For Atheros also the wprobe-utility from nbd,  a nice tool that make use out of this "mac-state" over time measurements, maybe you have heard about it ?
> 
> Does this make sense to you what I am interested in ?

The best and most accurate way to achieve this certainly is to
modify the firmware.
I don't know if the stock firmware provides enough information for
this without modification. You'll probably have to dig through the
specs wiki.

-- 
Greetings Michael.



From zajec5 at gmail.com  Tue Feb  8 17:32:17 2011
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Tue,  8 Feb 2011 23:32:17 +0100
Subject: [PATCH] ssb: extract boardflags2 for SPROMs rev 4 and 5
Message-ID: <1297204337-7932-1-git-send-email-zajec5@gmail.com>

Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>
---
 drivers/ssb/pci.c            |    4 ++++
 include/linux/ssb/ssb_regs.h |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/ssb/pci.c b/drivers/ssb/pci.c
index 158449e..5b33b3b 100644
--- a/drivers/ssb/pci.c
+++ b/drivers/ssb/pci.c
@@ -468,10 +468,14 @@ static void sprom_extract_r45(struct ssb_sprom *out, const u16 *in)
 		SPEX(country_code, SSB_SPROM4_CCODE, 0xFFFF, 0);
 		SPEX(boardflags_lo, SSB_SPROM4_BFLLO, 0xFFFF, 0);
 		SPEX(boardflags_hi, SSB_SPROM4_BFLHI, 0xFFFF, 0);
+		SPEX(boardflags2_lo, SSB_SPROM4_BFL2LO, 0xFFFF, 0);
+		SPEX(boardflags2_hi, SSB_SPROM4_BFL2HI, 0xFFFF, 0);
 	} else {
 		SPEX(country_code, SSB_SPROM5_CCODE, 0xFFFF, 0);
 		SPEX(boardflags_lo, SSB_SPROM5_BFLLO, 0xFFFF, 0);
 		SPEX(boardflags_hi, SSB_SPROM5_BFLHI, 0xFFFF, 0);
+		SPEX(boardflags2_lo, SSB_SPROM5_BFL2LO, 0xFFFF, 0);
+		SPEX(boardflags2_hi, SSB_SPROM5_BFL2HI, 0xFFFF, 0);
 	}
 	SPEX(ant_available_a, SSB_SPROM4_ANTAVAIL, SSB_SPROM4_ANTAVAIL_A,
 	     SSB_SPROM4_ANTAVAIL_A_SHIFT);
diff --git a/include/linux/ssb/ssb_regs.h b/include/linux/ssb/ssb_regs.h
index 489f7b6..df9211a 100644
--- a/include/linux/ssb/ssb_regs.h
+++ b/include/linux/ssb/ssb_regs.h
@@ -268,6 +268,8 @@
 /* SPROM Revision 4 */
 #define SSB_SPROM4_BFLLO		0x0044	/* Boardflags (low 16 bits) */
 #define SSB_SPROM4_BFLHI		0x0046  /* Board Flags Hi */
+#define SSB_SPROM4_BFL2LO		0x0048	/* Board flags 2 (low 16 bits) */
+#define SSB_SPROM4_BFL2HI		0x004A	/* Board flags 2 Hi */
 #define SSB_SPROM4_IL0MAC		0x004C	/* 6 byte MAC address for a/b/g/n */
 #define SSB_SPROM4_CCODE		0x0052	/* Country Code (2 bytes) */
 #define SSB_SPROM4_GPIOA		0x0056	/* Gen. Purpose IO # 0 and 1 */
@@ -358,6 +360,8 @@
 #define SSB_SPROM5_CCODE		0x0044	/* Country Code (2 bytes) */
 #define SSB_SPROM5_BFLLO		0x004A	/* Boardflags (low 16 bits) */
 #define SSB_SPROM5_BFLHI		0x004C  /* Board Flags Hi */
+#define SSB_SPROM5_BFL2LO		0x004E	/* Board flags 2 (low 16 bits) */
+#define SSB_SPROM5_BFL2HI		0x0050	/* Board flags 2 Hi */
 #define SSB_SPROM5_IL0MAC		0x0052	/* 6 byte MAC address for a/b/g/n */
 #define SSB_SPROM5_GPIOA		0x0076	/* Gen. Purpose IO # 0 and 1 */
 #define  SSB_SPROM5_GPIOA_P0		0x00FF	/* Pin 0 */
-- 
1.7.1



From mb at bu3sch.de  Wed Feb  9 02:59:18 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Wed, 09 Feb 2011 08:59:18 +0100
Subject: [PATCH] ssb: extract boardflags2 for SPROMs rev 4 and 5
In-Reply-To: <1297204337-7932-1-git-send-email-zajec5@gmail.com>
	(sfid-20110208_233235_389809_FFFFFFFFB9A7C8CA)
References: <1297204337-7932-1-git-send-email-zajec5@gmail.com>
	(sfid-20110208_233235_389809_FFFFFFFFB9A7C8CA)
Message-ID: <1297238358.9734.0.camel@maggie>

On Tue, 2011-02-08 at 23:32 +0100, Rafa? Mi?ecki wrote: 
> Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>

ack. John, please take this one through your tree.

> ---
>  drivers/ssb/pci.c            |    4 ++++
>  include/linux/ssb/ssb_regs.h |    4 ++++
>  2 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/ssb/pci.c b/drivers/ssb/pci.c
> index 158449e..5b33b3b 100644
> --- a/drivers/ssb/pci.c
> +++ b/drivers/ssb/pci.c
> @@ -468,10 +468,14 @@ static void sprom_extract_r45(struct ssb_sprom *out, const u16 *in)
>  		SPEX(country_code, SSB_SPROM4_CCODE, 0xFFFF, 0);
>  		SPEX(boardflags_lo, SSB_SPROM4_BFLLO, 0xFFFF, 0);
>  		SPEX(boardflags_hi, SSB_SPROM4_BFLHI, 0xFFFF, 0);
> +		SPEX(boardflags2_lo, SSB_SPROM4_BFL2LO, 0xFFFF, 0);
> +		SPEX(boardflags2_hi, SSB_SPROM4_BFL2HI, 0xFFFF, 0);
>  	} else {
>  		SPEX(country_code, SSB_SPROM5_CCODE, 0xFFFF, 0);
>  		SPEX(boardflags_lo, SSB_SPROM5_BFLLO, 0xFFFF, 0);
>  		SPEX(boardflags_hi, SSB_SPROM5_BFLHI, 0xFFFF, 0);
> +		SPEX(boardflags2_lo, SSB_SPROM5_BFL2LO, 0xFFFF, 0);
> +		SPEX(boardflags2_hi, SSB_SPROM5_BFL2HI, 0xFFFF, 0);
>  	}
>  	SPEX(ant_available_a, SSB_SPROM4_ANTAVAIL, SSB_SPROM4_ANTAVAIL_A,
>  	     SSB_SPROM4_ANTAVAIL_A_SHIFT);
> diff --git a/include/linux/ssb/ssb_regs.h b/include/linux/ssb/ssb_regs.h
> index 489f7b6..df9211a 100644
> --- a/include/linux/ssb/ssb_regs.h
> +++ b/include/linux/ssb/ssb_regs.h
> @@ -268,6 +268,8 @@
>  /* SPROM Revision 4 */
>  #define SSB_SPROM4_BFLLO		0x0044	/* Boardflags (low 16 bits) */
>  #define SSB_SPROM4_BFLHI		0x0046  /* Board Flags Hi */
> +#define SSB_SPROM4_BFL2LO		0x0048	/* Board flags 2 (low 16 bits) */
> +#define SSB_SPROM4_BFL2HI		0x004A	/* Board flags 2 Hi */
>  #define SSB_SPROM4_IL0MAC		0x004C	/* 6 byte MAC address for a/b/g/n */
>  #define SSB_SPROM4_CCODE		0x0052	/* Country Code (2 bytes) */
>  #define SSB_SPROM4_GPIOA		0x0056	/* Gen. Purpose IO # 0 and 1 */
> @@ -358,6 +360,8 @@
>  #define SSB_SPROM5_CCODE		0x0044	/* Country Code (2 bytes) */
>  #define SSB_SPROM5_BFLLO		0x004A	/* Boardflags (low 16 bits) */
>  #define SSB_SPROM5_BFLHI		0x004C  /* Board Flags Hi */
> +#define SSB_SPROM5_BFL2LO		0x004E	/* Board flags 2 (low 16 bits) */
> +#define SSB_SPROM5_BFL2HI		0x0050	/* Board flags 2 Hi */
>  #define SSB_SPROM5_IL0MAC		0x0052	/* 6 byte MAC address for a/b/g/n */
>  #define SSB_SPROM5_GPIOA		0x0076	/* Gen. Purpose IO # 0 and 1 */
>  #define  SSB_SPROM5_GPIOA_P0		0x00FF	/* Pin 0 */


-- 
Greetings Michael.



From zajec5 at gmail.com  Wed Feb  9 15:00:04 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Wed, 9 Feb 2011 21:00:04 +0100
Subject: Notes on ssb specs and implementation
Message-ID: <AANLkTimfTt7kiwtSiPfE0kYRXwgHXJPAv19xuiv-M=NG@mail.gmail.com>

Hi,

I've N-PHY card that doesn't report any scan results, so after
checking N-PHY code (it looks fine so far) I decided to dig into ssb.
Hopefully this will lead to some fixes and maybe working card.

I've dumped MMIO operations performed by wl and ssb/b43, compared
them, documented with parts from specs and noted differences.

As you should know, we have to enable wireless core twice: first time
to get basic information about hardware, second to configure it in
correct (like PHY specific) way.

ssb_device_enable_1 is for first reset
ssb_device_enable_2 is for second reset

Notes from ssb_device_enable_1:
1) There are few undocumented flushes performed by both drivers. Could
be nice to document it in specs
2) wl does not reset PHY (no B43_TMSLOW_PHYRESET and no taking it out
of reset after enabling wireless core)
3) After reset (last step in ssb_device_enable) wl doesn't leave core
specific flags

Notes from ssb_device_enable_2:
1) ssb does not implement fast disable in case clocks are not enabled
2) ssb uses different Reject bit than wl
3) ssb doesn't check for "If the Core ID Low register has the
"Initiator" bit set"
4) wl checks for "Busy" bit in IM STATE, not TM as documented in specs
5) when writing "Force Gated Clocks On", "Clock Enable", and "Reset"
both drivers keep Reject set, however specs don't mention that
6) wl checks "If the "Initiator" bit in TM State Low is set" using ff8
register which is Core ID Low, not TMSLOW
7) rest differences are duplicated from ssb_device_enable_1

Larry: could you care for specs notes I collected?

Michael: was there any reasons why we didn't implement some parts of
core-disabling code?
Michael: should we care about the way wl sets core specific flags? I
didn't dig into that moment in MMIO dumps, but as ssb_device_enable
implementation ignores flags at the end, it has to set flags somehow
differently on it's own.

-- 
Rafa?
-------------- next part --------------
wl:

>>> ssb_device_enable start
>>> ssb_device_disable start		Disable the Core to account for a core in a random state
ssb_read32(0xf98) -> 0x00000003		If the core is already in reset (the "Reset" bit in TM State Low is set) it's already disabled, return
ssb_read32(0xf98) -> 0x00000003		If the core is already in reset (the "Reset" bit in TM State Low is set) it's already disabled, return
>>> ssb_device_disable end

ssb_write32(0xf98) <- 0x00070001	(specific==B43_TMSLOW_PHYCLKEN) Write the "Force Gated Clocks On", "Clock Enable",and "Reset" bits along with any device specific flags requested, to the TM State Low register (unset the rest)
ssb_read32(0xf98) -> 0x00070001		Perform a dummy read on the TM State Low register

ssb_read32(0xf9c) -> 0x100c0000		If the S Error bit is set in the TM State High register
ssb_read32(0xf90) -> 0x00000020		Unset the "In Band Error" or "Timeout" bits if the IM State register has them set

ssb_write32(0xf98) <- 0x00070000	(specific==B43_TMSLOW_PHYCLKEN) Write the "Force Gated Clocks On", "Clock Enable" bits, along with any device specific flags requested, to the TM State Low register (unset the rest) 
ssb_read32(0xf98) -> 0x00070000		Perform a dummy read on the TM State Low register

ssb_write32(0xf98) <- 0x00010000	(Why no B43_TMSLOW_PHYCLKEN?) Write the "Clock Enable" bit along with any device specific flags requested to the TM State Low register (unset the rest)
ssb_read32(0xf98) -> 0x00010000		Undocumented flush
>>> ssb_device_enable end
-------------- next part --------------
b43/ssb:

>>> ssb_device_enable start
>>> ssb_device_disable start		Disable the Core to account for a core in a random state
ssb_read32(0xf98) -> 0x00000001		If the core is already in reset (the "Reset" bit in TM State Low is set) it's already disabled, return

>>> ssb_device_disable end

ssb_write32(0xf98) <- 0x000f0001	(specific==B43_TMSLOW_PHYCLKEN | B43_TMSLOW_PHYRESET) Write the "Force Gated Clocks On", "Clock Enable",and "Reset" bits along with any device specific flags requested, to the TM State Low register (unset the rest)
ssb_read32(0xf98) -> 0x000f0001		Perform a dummy read on the TM State Low register

ssb_read32(0xf9c) -> 0x10080000		If the S Error bit is set in the TM State High register
ssb_read32(0xf90) -> 0x00000020		Unset the "In Band Error" or "Timeout" bits if the IM State register has them set

ssb_write32(0xf98) <- 0x000f0000	(specific==B43_TMSLOW_PHYCLKEN | B43_TMSLOW_PHYRESET) Write the "Force Gated Clocks On", "Clock Enable" bits, along with any device specific flags requested, to the TM State Low register (unset the rest) 
ssb_read32(0xf98) -> 0x000f0000		Perform a dummy read on the TM State Low register

ssb_write32(0xf98) <- 0x000d0000	(specific==B43_TMSLOW_PHYCLKEN | B43_TMSLOW_PHYRESET) Write the "Clock Enable" bit along with any device specific flags requested to the TM State Low register (unset the rest)
ssb_read32(0xf98) -> 0x000d0000		Undocumented flush
>>> ssb_device_enable end

ssb_read32(0xf98) -> 0x000d0000		Unset the PHY Reset flag and set the Force Gated Clocks flag in TM State Low Flags
ssb_write32(0xf98) <- 0x00070000	Unset the PHY Reset flag and set the Force Gated Clocks flag in TM State Low Flags
ssb_read32(0xf98) -> 0x00070000		Undocumented flush

ssb_write32(0xf98) <- 0x00050000	Unset the Force Gated Clocks flag in TM State Low Flags
ssb_read32(0xf98) -> 0x00050000		Undocumented flush
-------------- next part --------------
wl:

>>> ssb_device_enable start
>>> ssb_device_disable start		Disable the Core to account for a core in a random state
ssb_read32(0xf98) -> 0x00010000		If the core is already in reset (the "Reset" bit in TM State Low is set) it's already disabled, return
ssb_read32(0xf98) -> 0x00010000		If clocks are not yet enabled (the "Clock Enabled" bit in TM State Low



ssb_write32(0xf98) <- 0x00010002	Set the "Reject" bit in TM State Low, which will cause the core to reject further input
ssb_read32(0xf98) -> 0x00010002		Perform a dummy read on the TM State Low register

ssb_read32(0xf9c) -> 0x100c0000		Wait until the "Busy" bit in TM State High is unset (or 100000 uS, checking every 10uSec)
ssb_read32(0xf9c) -> 0x100c0000		Wait until the "Busy" bit in TM State High is unset (or 100000 uS, checking every 10uSec)

 read32 0xc0200ff8 -> 0x410422c5	If the Core ID Low register has the "Initiator" bit set
ssb_read32(0xf90) -> 0x00000020		Set the "Reject" bit in the IM State register
ssb_write32(0xf90) <- 0x02000020	Set the "Reject" bit in the IM State register
ssb_read32(0xf90) -> 0x02000020		Perform a dummy read on the IM State register
ssb_read32(0xf90) -> 0x02000020		(TM != IM) Wait until the "Busy" bit in TM State is unset (of 100000 uS, checking every 10uS)

ssb_write32(0xf98) <- 0x00070003	(Reject is written!) (specific==B43_TMSLOW_PHYCLKEN) Write the "Force Gated Clocks On", "Clock Enable", and "Reset" bits along with any device specific flags requested, to the TM State Low register (unset the rest)
ssb_read32(0xf98) -> 0x00070003		Perform a dummy read on the TM State Low register

 read32 0xc0200ff8 -> 0x410422c5	(Core ID != TMSLOW) If the "Initiator" bit in TM State Low is set
ssb_read32(0xf90) -> 0x02000020		Clear the "Reject" bit in the IM State register
ssb_write32(0xf90) <- 0x00000020	Clear the "Reject" bit in the IM State register

ssb_write32(0xf98) <- 0x00040003	(specific==B43_TMSLOW_PHYCLKEN) Write the "Reset" and "Reject" bits along with any device specific flags requested to the TM State Low register

>>> ssb_device_disable end

ssb_write32(0xf98) <- 0x00070001	(specific==B43_TMSLOW_PHYCLKEN) Write the "Force Gated Clocks On", "Clock Enable",and "Reset" bits along with any device specific flags requested, to the TM State Low register (unset the rest)
ssb_read32(0xf98) -> 0x00070001		Perform a dummy read on the TM State Low register

ssb_read32(0xf9c) -> 0x100c0000		If the S Error bit is set in the TM State High register
ssb_read32(0xf90) -> 0x00000020		Unset the "In Band Error" or "Timeout" bits if the IM State register has them set

ssb_write32(0xf98) <- 0x00070000	(specific==B43_TMSLOW_PHYCLKEN) Write the "Force Gated Clocks On", "Clock Enable" bits, along with any device specific flags requested, to the TM State Low register (unset the rest) 
ssb_read32(0xf98) -> 0x00070000		Perform a dummy read on the TM State Low register

ssb_write32(0xf98) <- 0x00010000	(Why no B43_TMSLOW_PHYCLKEN?) Write the "Clock Enable" bit along with any device specific flags requested to the TM State Low register (unset the rest)
ssb_read32(0xf98) -> 0x00010000		Undocumented flush
>>> ssb_device_enable end
-------------- next part --------------
b43/ssb:

>>> ssb_device_enable start
>>> ssb_device_disable start		Disable the Core to account for a core in a random state
ssb_read32(0xf98) -> 0x00050000		If the core is already in reset (the "Reset" bit in TM State Low is set) it's already disabled, return 
					If clocks are not yet enabled (the "Clock Enabled" bit in TM State Low 
					Write the "Reset" and "Reject" bits along with any device specific flags requested to the TM State Low, wait 1uS, register and return

 read32 0xc0200ff8 -> 0x410422c5	ssb_tmslow_reject_bitmask
ssb_write32(0xf98) <- 0x00010004	Set the "Reject" bit in TM State Low, which will cause the core to reject further input
ssb_read32(0xf98) -> 0x00010004		Perform a dummy read on the TM State Low register

ssb_read32(0xf9c) -> 0x10080000		Wait until the "Busy" bit in TM State High is unset (or 100000 uS, checking every 10uSec)


?					If the Core ID Low register has the "Initiator" bit set





ssb_write32(0xf98) <- 0x204f0005	Write the "Force Gated Clocks On", "Clock Enable", and "Reset" bits along with any device specific flags requested, to the TM State Low register (unset the rest)
ssb_read32(0xf98) -> 0x204f0005		Perform a dummy read on the TM State Low register

?					If the "Initiator" bit in TM State Low is set 
?					Clear the "Reject" bit in the IM State register


ssb_write32(0xf98) <- 0x204c0005	Write the "Reset" and "Reject" bits along with any device specific flags requested to the TM State Low register
ssb_read32(0xf98) -> 0x204c0005		Undocumented flush
>>> ssb_device_disable end

ssb_write32(0xf98) <- 0x204f0001	(specific==B43_TMSLOW_PHYCLKEN | B43_TMSLOW_PHYRESET | B43_TMSLOW_GMODE | B43_TMSLOW_PHY_BANDWIDTH_20MHZ) Write the "Force Gated Clocks On", "Clock Enable",and "Reset" bits along with any device specific flags requested, to the TM State Low register (unset the rest)
ssb_read32(0xf98) -> 0x204f0001		Perform a dummy read on the TM State Low register

ssb_read32(0xf9c) -> 0x10080000		If the S Error bit is set in the TM State High register
ssb_read32(0xf90) -> 0x00000020		Unset the "In Band Error" or "Timeout" bits if the IM State register has them set

ssb_write32(0xf98) <- 0x204f0000	(specific==B43_TMSLOW_PHYCLKEN | B43_TMSLOW_PHYRESET | B43_TMSLOW_GMODE | B43_TMSLOW_PHY_BANDWIDTH_20MHZ) Write the "Force Gated Clocks On", "Clock Enable" bits, along with any device specific flags requested, to the TM State Low register (unset the rest) 
ssb_read32(0xf98) -> 0x204f0000		Perform a dummy read on the TM State Low register

ssb_write32(0xf98) <- 0x204d0000	(specific==B43_TMSLOW_PHYCLKEN | B43_TMSLOW_PHYRESET | B43_TMSLOW_GMODE | B43_TMSLOW_PHY_BANDWIDTH_20MHZ) Write the "Clock Enable" bit along with any device specific flags requested to the TM State Low register (unset the rest)
ssb_read32(0xf98) -> 0x204d0000		Undocumented flush
>>> ssb_device_enable end

ssb_read32(0xf98) -> 0x204d0000		Unset the PHY Reset flag and set the Force Gated Clocks flag in TM State Low Flags
ssb_write32(0xf98) <- 0x20470000	Unset the PHY Reset flag and set the Force Gated Clocks flag in TM State Low Flags
ssb_read32(0xf98) -> 0x20470000		Undocumented flush

ssb_write32(0xf98) <- 0x20450000	Unset the Force Gated Clocks flag in TM State Low Flags
ssb_read32(0xf98) -> 0x20450000		Undocumented flush

From mb at bu3sch.de  Wed Feb  9 15:17:01 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Wed, 09 Feb 2011 21:17:01 +0100
Subject: Notes on ssb specs and implementation
In-Reply-To: <AANLkTimfTt7kiwtSiPfE0kYRXwgHXJPAv19xuiv-M=NG@mail.gmail.com>
	(sfid-20110209_210017_862769_37B0C3E4)
References: <AANLkTimfTt7kiwtSiPfE0kYRXwgHXJPAv19xuiv-M=NG@mail.gmail.com>
	(sfid-20110209_210017_862769_37B0C3E4)
Message-ID: <1297282621.9734.5.camel@maggie>

On Wed, 2011-02-09 at 21:00 +0100, Rafa? Mi?ecki wrote: 
> Michael: was there any reasons why we didn't implement some parts of
> core-disabling code?

The function are complete as of latest reverse engineering efforts.
Broadcom added stuff, if they do more stuff in latest code.

> Michael: should we care about the way wl sets core specific flags? I
> didn't dig into that moment in MMIO dumps, but as ssb_device_enable
> implementation ignores flags at the end, it has to set flags somehow
> differently on it's own.

I have no idea. ssb_device_enable is very hairy and I'm not going
to touch it without good reason and regression testing.

You didn't tell us the important part: Does changing ssb_device_enable
make it work?

-- 
Greetings Michael.



From anisse at astier.eu  Thu Feb 10 12:16:42 2011
From: anisse at astier.eu (Anisse Astier)
Date: Thu, 10 Feb 2011 18:16:42 +0100
Subject: LP PHY Dell device not working properly with b43 even in PIO mode
Message-ID: <20110210181642.760948f3@destiny.ordissimo>

Hi,

Running John Linville's wireless-next tree(HEAD:
6d1d4ea4a82f8c17a3ff7c2f677bc3d41ea7484b), I have troubles with a
Broadcom wireless card that can't properly connect. This device is also
managed by wl, that supports it more or less properly (at least without
crashing). AFAIK, the card isn't supported by brcm80211.

It can connect, and even get an IP, but after some time it will just stop
working until reboot. The AP uses WPA2-PSK/TKIP.


The device:
0e:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g LP-PHY [14e4:4315] (rev 01)
	Subsystem: Dell Wireless 1397 WLAN Mini-Card [1028:000c]

The log (I have similar problems if I load it directly in PIO mode) :
[   92.717848] cfg80211: Calling CRDA to update world regulatory domain
[   92.794368] b43-pci-bridge 0000:0e:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[   92.794385] b43-pci-bridge 0000:0e:00.0: setting latency timer to 64
[   92.802294] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x16, vendor 0x4243)
[   92.802312] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0F, vendor 0x4243)
[   92.802329] ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x0A, vendor 0x4243)
[   92.802346] ssb: Core 3 found: PCI-E (cc 0x820, rev 0x09, vendor 0x4243)
[   92.827567] ssb: Sonics Silicon Backplane found on PCI device 0000:0e:00.0
[   92.864178] b43-phy0: Broadcom 4312 WLAN found (core revision 15)
[   92.879241] b43-phy0 debug: Found PHY: Analog 6, Type 5, Revision 1
[   92.879257] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 2
[   92.914280] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   92.914449] Registered led device: b43-phy0::tx
[   92.914466] Registered led device: b43-phy0::rx
[   92.914481] Registered led device: b43-phy0::radio
[   92.914494] Broadcom 43xx driver loaded [ Features: PL, Firmware-ID: FW13 ]
[   93.148262] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
[   93.151103] b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz.
[   94.535309] b43-phy0 debug: Chip initialized
[   94.535482] b43-phy0 debug: 64-bit DMA initialized
[   94.535581] b43-phy0 debug: QoS enabled
[   94.544613] b43-phy0 debug: Wireless interface started
[   94.548369] b43-phy0 debug: Adding Interface type 2
[   98.639420] b43-phy0 debug: Removing Interface type 2
[   98.642253] b43-phy0 debug: Wireless interface stopped
[   98.642969] b43-phy0 debug: DMA-64 rx_ring: Used slots 1/64, Failed frames 0/0 = 0.0%, Average tries 0.00
[   98.643017] b43-phy0 debug: DMA-64 tx_ring_AC_BK: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00
[   98.645042] b43-phy0 debug: DMA-64 tx_ring_AC_BE: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00
[   98.647042] b43-phy0 debug: DMA-64 tx_ring_AC_VI: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00
[   98.649042] b43-phy0 debug: DMA-64 tx_ring_AC_VO: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00
[   98.651041] b43-phy0 debug: DMA-64 tx_ring_mcast: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00
[   99.799265] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
[   99.802104] b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz.
[  101.186309] b43-phy0 debug: Chip initialized
[  101.186467] b43-phy0 debug: 64-bit DMA initialized
[  101.186566] b43-phy0 debug: QoS enabled
[  101.195651] b43-phy0 debug: Wireless interface started
[  101.202186] b43-phy0 debug: Adding Interface type 2
[  103.622973] wlan0: authenticate with 68:7f:74:16:57:c9 (try 1)
[  103.624654] wlan0: authenticated
[  103.624666] wlan0: associate with 68:7f:74:16:57:c9 (try 1)
[  103.627181] wlan0: RX AssocResp from 68:7f:74:16:57:c9 (capab=0x411 status=0 aid=2)
[  103.627184] wlan0: associated
[  103.677583] b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: 68:7f:74:16:57:c9
[  148.586756] b43-phy0 ERROR: Fatal DMA error: 0x00000800, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
[  148.586788] b43-phy0 ERROR: This device does not support DMA on your system. It will now be switched to PIO.
[  148.586791] b43-phy0: Controller RESET (DMA error) ...
[  148.586794] b43-phy0 ERROR: Fatal DMA error: 0x00000800, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
[  148.586797] b43-phy0 ERROR: This device does not support DMA on your system. It will now be switched to PIO.
[  148.586800] b43-phy0: Controller RESET (DMA error) ...
[  148.586882] b43-phy0 debug: Wireless interface stopped
[  148.587137] b43-phy0 debug: DMA-64 rx_ring: Used slots 2/64, Failed frames 0/0 = 0.0%, Average tries 0.00
[  148.587179] b43-phy0 debug: DMA-64 tx_ring_AC_BK: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00
[  148.589052] b43-phy0 debug: DMA-64 tx_ring_AC_BE: Used slots 24/256, Failed frames 0/246 = 0.0%, Average tries 1.06
[  148.591045] b43-phy0 debug: DMA-64 tx_ring_AC_VI: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00
[  148.593050] b43-phy0 debug: DMA-64 tx_ring_AC_VO: Used slots 4/256, Failed frames 0/69 = 0.0%, Average tries 1.05
[  148.595043] b43-phy0 debug: DMA-64 tx_ring_mcast: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00
[  148.741245] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
[  148.744095] b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz.
[  150.202291] b43-phy0 debug: Chip initialized
[  150.202395] b43-phy0 debug: PIO initialized
[  150.202499] b43-phy0 debug: QoS enabled
[  150.215702] b43-phy0 debug: Wireless interface started
[  150.215705] b43-phy0: Controller restarted
[  180.211047] ieee80211 phy0: wlan0: No probe response from AP 68:7f:74:16:57:c9 after 500ms, disconnecting.
[  180.291042] b43-phy0 ERROR: MAC suspend failed
[  180.371040] b43-phy0 ERROR: MAC suspend failed
[  180.453042] b43-phy0 ERROR: MAC suspend failed
[  180.533040] b43-phy0 ERROR: MAC suspend failed
[  180.613040] b43-phy0 ERROR: MAC suspend failed
[  180.694042] b43-phy0 ERROR: MAC suspend failed
[  180.694272] b43-phy0 debug: Disabling hardware based encryption for keyidx: 0, mac: 68:7f:74:16:57:c9
[  180.774042] b43-phy0 ERROR: MAC suspend failed
[  180.854042] b43-phy0 ERROR: MAC suspend failed
[  180.863322] cfg80211: Calling CRDA to update world regulatory domain
[  181.044024] b43-phy0 ERROR: MAC suspend failed
[  181.124024] b43-phy0 ERROR: MAC suspend failed
[  181.364307] b43-phy0 debug: Removing Interface type 2
[  181.444042] b43-phy0 ERROR: MAC suspend failed
[  181.444250] b43-phy0 debug: Wireless interface stopped
[  182.768267] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
[  182.771109] b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz.
[  184.163310] b43-phy0 debug: Chip initialized
[  184.163412] b43-phy0 debug: PIO initialized
[  184.163513] b43-phy0 debug: QoS enabled
[  184.172751] b43-phy0 debug: Wireless interface started
[  184.176365] b43-phy0 debug: Adding Interface type 2
[  217.409345] wlan0: authenticate with 68:7f:74:16:57:c9 (try 1)
[  217.411182] wlan0: authenticated
[  217.411197] wlan0: associate with 68:7f:74:16:57:c9 (try 1)
[  217.413812] wlan0: RX AssocResp from 68:7f:74:16:57:c9 (capab=0x411 status=0 aid=2)
[  217.413815] wlan0: associated
[  221.213048] ieee80211 phy0: wlan0: No probe response from AP 68:7f:74:16:57:c9 after 500ms, disconnecting.
[  221.213914] cfg80211: Calling CRDA to update world regulatory domain
[  221.593041] net_ratelimit: 2 callbacks suppressed
[  221.593044] b43-phy0 ERROR: MAC suspend failed
[  221.742041] b43-phy0 ERROR: MAC suspend failed
[  222.096041] b43-phy0 ERROR: MAC suspend failed
[  222.898327] wlan0: authenticate with 68:7f:74:16:57:c9 (try 1)
[  223.098047] wlan0: authenticate with 68:7f:74:16:57:c9 (try 2)
[  223.298046] wlan0: authenticate with 68:7f:74:16:57:c9 (try 3)
[  223.498045] wlan0: authentication with 68:7f:74:16:57:c9 timed out
[  223.578040] b43-phy0 ERROR: MAC suspend failed
[  223.660082] b43-phy0 ERROR: MAC suspend failed
[  233.163041] b43-phy0 ERROR: MAC suspend failed
[  233.314041] b43-phy0 ERROR: MAC suspend failed
[  233.563041] b43-phy0 ERROR: MAC suspend failed
[  233.713042] b43-phy0 ERROR: MAC suspend failed
[  233.862042] b43-phy0 ERROR: MAC suspend failed
[  234.011041] b43-phy0 ERROR: MAC suspend failed
[  234.160040] b43-phy0 ERROR: MAC suspend failed
[  234.309041] b43-phy0 ERROR: MAC suspend failed
[  234.460042] b43-phy0 ERROR: MAC suspend failed
[  234.747041] b43-phy0 ERROR: MAC suspend failed
[  240.312042] net_ratelimit: 1 callbacks suppressed
[  240.312045] b43-phy0 ERROR: MAC suspend failed
[  240.461042] b43-phy0 ERROR: MAC suspend failed
[  240.711042] b43-phy0 ERROR: MAC suspend failed
[  240.860042] b43-phy0 ERROR: MAC suspend failed
[  241.009041] b43-phy0 ERROR: MAC suspend failed
[  241.158041] b43-phy0 ERROR: MAC suspend failed
[  241.308042] b43-phy0 ERROR: MAC suspend failed
[  241.459043] b43-phy0 ERROR: MAC suspend failed
[  241.608040] b43-phy0 ERROR: MAC suspend failed
[  241.757041] b43-phy0 ERROR: MAC suspend failed
[  247.554043] net_ratelimit: 2 callbacks suppressed
[  247.554046] b43-phy0 ERROR: MAC suspend failed
[  247.704041] b43-phy0 ERROR: MAC suspend failed
[  247.953042] b43-phy0 ERROR: MAC suspend failed
[  248.209041] b43-phy0 ERROR: MAC suspend failed
[  248.358044] b43-phy0 ERROR: MAC suspend failed
[  248.512020] b43-phy0 ERROR: MAC suspend failed
[  248.664013] b43-phy0 ERROR: MAC suspend failed
[  248.814041] b43-phy0 ERROR: MAC suspend failed
[  248.966041] b43-phy0 ERROR: MAC suspend failed
[  249.117041] b43-phy0 ERROR: MAC suspend failed
[  254.927031] b43-phy0 ERROR: MAC suspend failed
[  255.160014] b43-phy0 ERROR: MAC suspend failed
[  255.309013] b43-phy0 ERROR: MAC suspend failed
[  255.458013] b43-phy0 ERROR: MAC suspend failed
[  255.612024] b43-phy0 ERROR: MAC suspend failed
[  255.761041] b43-phy0 ERROR: MAC suspend failed
[  261.618043] b43-phy0 ERROR: MAC suspend failed
[  261.867042] b43-phy0 ERROR: MAC suspend failed
[  262.017041] b43-phy0 ERROR: MAC suspend failed
[  262.166041] b43-phy0 ERROR: MAC suspend failed
[  262.317041] b43-phy0 ERROR: MAC suspend failed
[  262.466041] b43-phy0 ERROR: MAC suspend failed
[  262.615029] b43-phy0 ERROR: MAC suspend failed
[  262.765041] b43-phy0 ERROR: MAC suspend failed
[  268.464043] b43-phy0 ERROR: MAC suspend failed
[  268.613078] b43-phy0 ERROR: MAC suspend failed
[  268.863042] b43-phy0 ERROR: MAC suspend failed
[  269.141042] b43-phy0 ERROR: MAC suspend failed
[  269.292041] b43-phy0 ERROR: MAC suspend failed
[  269.441042] b43-phy0 ERROR: MAC suspend failed
[  269.590044] b43-phy0 ERROR: MAC suspend failed
[  269.922041] b43-phy0 ERROR: MAC suspend failed
[  270.072041] b43-phy0 ERROR: MAC suspend failed
[  270.221042] b43-phy0 ERROR: MAC suspend failed
[  275.635042] net_ratelimit: 1 callbacks suppressed
[  275.635045] b43-phy0 ERROR: MAC suspend failed
[  275.785042] b43-phy0 ERROR: MAC suspend failed
[  276.034043] b43-phy0 ERROR: MAC suspend failed
[  276.183041] b43-phy0 ERROR: MAC suspend failed
[  276.332042] b43-phy0 ERROR: MAC suspend failed
[  276.481041] b43-phy0 ERROR: MAC suspend failed
[  276.630041] b43-phy0 ERROR: MAC suspend failed
[  276.779042] b43-phy0 ERROR: MAC suspend failed
[  276.928041] b43-phy0 ERROR: MAC suspend failed
[  282.691042] b43-phy0 ERROR: MAC suspend failed
[  282.841042] b43-phy0 ERROR: MAC suspend failed
[  283.091042] b43-phy0 ERROR: MAC suspend failed
[  283.241042] b43-phy0 ERROR: MAC suspend failed
[  283.390041] b43-phy0 ERROR: MAC suspend failed
[  283.539042] b43-phy0 ERROR: MAC suspend failed
[  283.688042] b43-phy0 ERROR: MAC suspend failed
[  283.837790] b43-phy0 ERROR: MAC suspend failed
[  283.987041] b43-phy0 ERROR: MAC suspend failed
[  284.136041] b43-phy0 ERROR: MAC suspend failed
[  287.174502] r8169 0000:08:00.0: eth0: link up
[  290.002046] net_ratelimit: 3 callbacks suppressed
[  290.002049] b43-phy0 ERROR: MAC suspend failed
[  290.493042] b43-phy0 ERROR: MAC suspend failed
[  290.642041] b43-phy0 ERROR: MAC suspend failed
[  290.791041] b43-phy0 ERROR: MAC suspend failed
[  290.940042] b43-phy0 ERROR: MAC suspend failed
[  291.090042] b43-phy0 ERROR: MAC suspend failed
[  291.242042] b43-phy0 ERROR: MAC suspend failed
[  291.475042] b43-phy0 ERROR: MAC suspend failed
[  291.624041] b43-phy0 ERROR: MAC suspend failed
[  297.041042] b43-phy0 ERROR: MAC suspend failed
[  297.190041] b43-phy0 ERROR: MAC suspend failed
[  297.440044] b43-phy0 ERROR: MAC suspend failed
[  297.703041] b43-phy0 ERROR: MAC suspend failed
[  297.854043] b43-phy0 ERROR: MAC suspend failed
[  298.003042] b43-phy0 ERROR: MAC suspend failed
[  298.152047] b43-phy0 ERROR: MAC suspend failed
[  298.301042] b43-phy0 ERROR: MAC suspend failed
[  298.452044] b43-phy0 ERROR: MAC suspend failed
[ ?] you get the idea

Regards,

Anisse


From Larry.Finger at lwfinger.net  Thu Feb 10 12:41:57 2011
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Thu, 10 Feb 2011 11:41:57 -0600
Subject: LP PHY Dell device not working properly with b43 even in PIO mode
In-Reply-To: <20110210181642.760948f3@destiny.ordissimo>
References: <20110210181642.760948f3@destiny.ordissimo>
Message-ID: <4D542365.6060307@lwfinger.net>

On 02/10/2011 11:16 AM, Anisse Astier wrote:
> [  103.627184] wlan0: associated
> [  103.677583] b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: 68:7f:74:16:57:c9
> [  148.586756] b43-phy0 ERROR: Fatal DMA error: 0x00000800, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
> [  148.586788] b43-phy0 ERROR: This device does not support DMA on your system. It will now be switched to PIO.
> [  148.586791] b43-phy0: Controller RESET (DMA error) ...
> [  148.586794] b43-phy0 ERROR: Fatal DMA error: 0x00000800, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
> [  148.586797] b43-phy0 ERROR: This device does not support DMA on your system. It will now be switched to PIO.
> [  148.586800] b43-phy0: Controller RESET (DMA error) ...
> [  148.586882] b43-phy0 debug: Wireless interface stopped

On some boxes, 14e4:4315 devices fail in b43 with with this DMA error. We don't
know why, nor do we know how to fix it. Unfortunately, none of the developers
have such a system, which makes the debugging harder.

I don't think the problem is with the Dell 1397, but with the motherboard on the
laptop. In fact, most of the problems have been with netbook computers with a
Phoenix BIOS. Does your system fit that description?

> [  297.703041] b43-phy0 ERROR: MAC suspend failed
> [  297.854043] b43-phy0 ERROR: MAC suspend failed
> [  298.003042] b43-phy0 ERROR: MAC suspend failed

Are the MAC suspend failures in PIO mode a regression that recently appeared? I
cannot think of any changes that should have affected the LP PHY devices, but
anything is possible.

The only workaround I can suggest is to use wl. I hate to recommend
closed-source software, but there may be no alternative.


Larry


From anisse at astier.eu  Thu Feb 10 13:30:07 2011
From: anisse at astier.eu (Anisse Astier)
Date: Thu, 10 Feb 2011 19:30:07 +0100
Subject: LP PHY Dell device not working properly with b43 even in PIO mode
In-Reply-To: <4D542365.6060307@lwfinger.net>
References: <20110210181642.760948f3@destiny.ordissimo>
	<4D542365.6060307@lwfinger.net>
Message-ID: <20110210193007.25362a0b@destiny.ordissimo>

On Thu, 10 Feb 2011 11:41:57 -0600, Larry Finger <Larry.Finger at lwfinger.net> wrote :

> On 02/10/2011 11:16 AM, Anisse Astier wrote:
> > [  103.627184] wlan0: associated
> > [  103.677583] b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: 68:7f:74:16:57:c9
> > [  148.586756] b43-phy0 ERROR: Fatal DMA error: 0x00000800, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
> > [  148.586788] b43-phy0 ERROR: This device does not support DMA on your system. It will now be switched to PIO.
> > [  148.586791] b43-phy0: Controller RESET (DMA error) ...
> > [  148.586794] b43-phy0 ERROR: Fatal DMA error: 0x00000800, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
> > [  148.586797] b43-phy0 ERROR: This device does not support DMA on your system. It will now be switched to PIO.
> > [  148.586800] b43-phy0: Controller RESET (DMA error) ...
> > [  148.586882] b43-phy0 debug: Wireless interface stopped
> 
> On some boxes, 14e4:4315 devices fail in b43 with with this DMA error. We don't
> know why, nor do we know how to fix it. Unfortunately, none of the developers
> have such a system, which makes the debugging harder.
> 
> I don't think the problem is with the Dell 1397, but with the motherboard on the
> laptop. In fact, most of the problems have been with netbook computers with a
> Phoenix BIOS. Does your system fit that description?
It's indeed a Phoenix Bios. Machine model is Dell Vostro 1520, but
definitely not a netbook.

> 
> > [  297.703041] b43-phy0 ERROR: MAC suspend failed
> > [  297.854043] b43-phy0 ERROR: MAC suspend failed
> > [  298.003042] b43-phy0 ERROR: MAC suspend failed
> 
> Are the MAC suspend failures in PIO mode a regression that recently appeared? I
> cannot think of any changes that should have affected the LP PHY devices, but
> anything is possible.
> 
> The only workaround I can suggest is to use wl. I hate to recommend
> closed-source software, but there may be no alternative.
Yep, I already packaged that driver, and planned to use it. I was in the
mode give-every-time-I-have-left to b43 developers to test patches and
try to find a solution.


Anisse


From zajec5 at gmail.com  Mon Feb 14 07:28:00 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Mon, 14 Feb 2011 13:28:00 +0100
Subject: Interesting note on "Unsupported SPROM revision"
Message-ID: <AANLkTinJDQDjhnzMBPubNkowxrXFDfOEz83HA1fHgEDU@mail.gmail.com>

I wanted to be lazy and have 2 cards in my PC at the same time. So I
tried putting my mini PCIe adapter to PCIe x8 slot instead of PCIe x1
slot.

That resulted in:
[    6.681088] ssb: PCI-ID not in fallback list
[    6.681251] ssb: CHIPID not in nrcores fallback list
[    6.681433] ssb: Core 0 found: UNKNOWN (cc 0x8FF, rev 0x7F, vendor 0xFFFF)
[    6.689462] ssb: WARNING: Invalid SPROM CRC (corrupt SPROM)
[    6.689467] ssb: Unsupported SPROM  revision 255 detected. Will extract v1
[    6.697123] ssb: Sonics Silicon Backplane found on PCI device 0000:02:00.0
[  277.718506] wl: module license 'unspecified' taints kernel.
[  277.718513] Disabling lock debugging due to kernel taint
[  277.744813] wl 0000:02:00.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24
[  277.744832] wl 0000:02:00.0: setting latency timer to 64
[  277.745126] eth%d: 5.100.82.38 driver failed with code 11

Instead of:
[    6.615095] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x17, vendor 0x4243)
[    6.615109] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x10,
vendor 0x4243)
[    6.615120] ssb: Core 2 found: PCI-E (cc 0x820, rev 0x0B, vendor 0x4243)
[    6.615132] ssb: Core 3 found: PCI (cc 0x804, rev 0x0E, vendor 0x4243)
[    6.615144] ssb: Core 4 found: USB 2.0 Device (cc 0x81A, rev 0x05,
vendor 0x4243)
[    6.615156] ssb: Core 5 found: UNKNOWN (cc 0x8FF, rev 0x00, vendor 0x4243)
[    6.615167] ssb: Core 6 found: Internal Memory (cc 0x80E, rev 0x03,
vendor 0x4243)
[    6.639312] ssb: Sonics Silicon Backplane found on PCI device 0000:03:00.0

Just wanted to put it on ML in case someone will ever hit that issue.

-- 
Rafa?


From mb at bu3sch.de  Mon Feb 14 15:29:55 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Mon, 14 Feb 2011 21:29:55 +0100
Subject: Interesting note on "Unsupported SPROM revision"
In-Reply-To: <AANLkTinJDQDjhnzMBPubNkowxrXFDfOEz83HA1fHgEDU@mail.gmail.com>
	(sfid-20110214_072801_981891_D319F6EF)
References: <AANLkTinJDQDjhnzMBPubNkowxrXFDfOEz83HA1fHgEDU@mail.gmail.com>
	(sfid-20110214_072801_981891_D319F6EF)
Message-ID: <1297715395.11070.5.camel@Nokia-N900>

> That resulted in:
> [? ? ?  6.681088] ssb: PCI-ID not in fallback list
> [? ? ?  6.681251] ssb: CHIPID not in nrcores fallback list
> [? ? ?  6.681433] ssb: Core 0 found: UNKNOWN (cc 0x8FF, rev 0x7F, vendor
> 0xFFFF) [? ? ?  6.689462] ssb: WARNING: Invalid SPROM CRC (corrupt SPROM)
> [? ? ?  6.689467] ssb: Unsupported SPROM?  revision 255 detected. Will
> extract v1 [? ? ?  6.697123] ssb: Sonics Silicon Backplane found on PCI
> 
> Just wanted to put it on ML in case someone will ever hit that issue.
> 

all mmio reads return all-ones. That usually means your pci(e) does not work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110214/9d9230df/attachment.html>

From zajec5 at gmail.com  Mon Feb 14 14:51:54 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Mon, 14 Feb 2011 20:51:54 +0100
Subject: Notes on ssb specs and implementation
In-Reply-To: <1297282621.9734.5.camel@maggie>
References: <AANLkTimfTt7kiwtSiPfE0kYRXwgHXJPAv19xuiv-M=NG@mail.gmail.com>
	<1297282621.9734.5.camel@maggie>
Message-ID: <AANLkTinjDMSCqxWbAfjZO_JkfBZeRoAZOG5Pxvf1v8Xr@mail.gmail.com>

W dniu 9 lutego 2011 21:17 u?ytkownik Michael B?sch <mb at bu3sch.de> napisa?:
> On Wed, 2011-02-09 at 21:00 +0100, Rafa? Mi?ecki wrote:
>> Michael: was there any reasons why we didn't implement some parts of
>> core-disabling code?
>
> The function are complete as of latest reverse engineering efforts.
> Broadcom added stuff, if they do more stuff in latest code.

Nothing has changed in specs since 2006:
http://bcm-v4.sipsolutions.net/Backplane?action=info
For some reason routines that were present even in 2006 was not implemented.


>> Michael: should we care about the way wl sets core specific flags? I
>> didn't dig into that moment in MMIO dumps, but as ssb_device_enable
>> implementation ignores flags at the end, it has to set flags somehow
>> differently on it's own.
>
> I have no idea. ssb_device_enable is very hairy and I'm not going
> to touch it without good reason and regression testing.
>
> You didn't tell us the important part: Does changing ssb_device_enable
> make it work?

I've just written missing parts, tested and it still does not work :|
The only advantage discovered so far is that ssb detects sth is wrong
with IM state:
[ 2661.449647] ssb: Timeout waiting for bitmask 01800000 on register
0F90 to clear.

I can see wl experiencing the same problems after loading b43. It
reads 0xf90 dozen of times in a row.

-- 
Rafa?


From mb at bu3sch.de  Mon Feb 14 17:01:17 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Mon, 14 Feb 2011 23:01:17 +0100
Subject: Notes on ssb specs and implementation
In-Reply-To: <AANLkTinjDMSCqxWbAfjZO_JkfBZeRoAZOG5Pxvf1v8Xr@mail.gmail.com>
	(sfid-20110214_205318_109392_FFFFFFFFAA87CB50)
References: <AANLkTimfTt7kiwtSiPfE0kYRXwgHXJPAv19xuiv-M=NG@mail.gmail.com>
	<1297282621.9734.5.camel@maggie>
	<AANLkTinjDMSCqxWbAfjZO_JkfBZeRoAZOG5Pxvf1v8Xr@mail.gmail.com>
	(sfid-20110214_205318_109392_FFFFFFFFAA87CB50)
Message-ID: <1297720877.5683.3.camel@maggie>

On Mon, 2011-02-14 at 20:51 +0100, Rafa? Mi?ecki wrote: 
> W dniu 9 lutego 2011 21:17 u?ytkownik Michael B?sch <mb at bu3sch.de> napisa?:
> > On Wed, 2011-02-09 at 21:00 +0100, Rafa? Mi?ecki wrote:
> >> Michael: was there any reasons why we didn't implement some parts of
> >> core-disabling code?
> >
> > The function are complete as of latest reverse engineering efforts.
> > Broadcom added stuff, if they do more stuff in latest code.
> 
> Nothing has changed in specs since 2006:
> http://bcm-v4.sipsolutions.net/Backplane?action=info
> For some reason routines that were present even in 2006 was not implemented.

Well, so the function was implemented prior to 2006. Which doesn't
surprise me. It was one of the first ones.

> I've just written missing parts,

May I see them?

> tested and it still does not work :|
> The only advantage discovered so far is that ssb detects sth is wrong
> with IM state:
> [ 2661.449647] ssb: Timeout waiting for bitmask 01800000 on register
> 0F90 to clear.
> 
> I can see wl experiencing the same problems after loading b43. It
> reads 0xf90 dozen of times in a row.

And that's the thing why I always avoid touching that function.
There's so much magic going on, so that completely weird things happen
all the time. :D

-- 
Greetings Michael.



From zajec5 at gmail.com  Mon Feb 14 17:32:05 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Mon, 14 Feb 2011 23:32:05 +0100
Subject: Notes on ssb specs and implementation
In-Reply-To: <1297720877.5683.3.camel@maggie>
References: <AANLkTimfTt7kiwtSiPfE0kYRXwgHXJPAv19xuiv-M=NG@mail.gmail.com>
	<1297282621.9734.5.camel@maggie>
	<AANLkTinjDMSCqxWbAfjZO_JkfBZeRoAZOG5Pxvf1v8Xr@mail.gmail.com>
	<1297720877.5683.3.camel@maggie>
Message-ID: <AANLkTi=ayavFKJw9s-n-AvMDrtMxXdDcjV+BnoxO-qkE@mail.gmail.com>

W dniu 14 lutego 2011 23:01 u?ytkownik Michael B?sch <mb at bu3sch.de> napisa?:
> On Mon, 2011-02-14 at 20:51 +0100, Rafa? Mi?ecki wrote:
>> W dniu 9 lutego 2011 21:17 u?ytkownik Michael B?sch <mb at bu3sch.de> napisa?:
>> > On Wed, 2011-02-09 at 21:00 +0100, Rafa? Mi?ecki wrote:
>> >> Michael: was there any reasons why we didn't implement some parts of
>> >> core-disabling code?
>> >
>> > The function are complete as of latest reverse engineering efforts.
>> > Broadcom added stuff, if they do more stuff in latest code.
>>
>> Nothing has changed in specs since 2006:
>> http://bcm-v4.sipsolutions.net/Backplane?action=info
>> For some reason routines that were present even in 2006 was not implemented.
>
> Well, so the function was implemented prior to 2006. Which doesn't
> surprise me. It was one of the first ones.
>
>> I've just written missing parts,
>
> May I see them?

Sure. It's not for submission, so you have to expect magic values.


>> tested and it still does not work :|
>> The only advantage discovered so far is that ssb detects sth is wrong
>> with IM state:
>> [ 2661.449647] ssb: Timeout waiting for bitmask 01800000 on register
>> 0F90 to clear.
>>
>> I can see wl experiencing the same problems after loading b43. It
>> reads 0xf90 dozen of times in a row.
>
> And that's the thing why I always avoid touching that function.
> There's so much magic going on, so that completely weird things happen
> all the time. :D

Hm, that looks pretty easy and not really complicated. Of course, if
you figure out how it's working.

Personally I don't like for example description at
http://bcm-v4.sipsolutions.net/802.11/PHY . It's really messed in "Put
PHY Into Reset".
Section "Put PHY Into Reset" is really "How to reset PHY" and it
duplicates code of takine PHY out of reset.

We also have a lot of magic in ssb_device_enable. We reset SB and PHY
at the same time. I guess it introduces some optimization but makes it
harder to understand, especially if you try to understand implemented
code and look as specs at the same time.

-- 
Rafa?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssb.initiator.patch
Type: application/octet-stream
Size: 1299 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110214/737fd896/attachment.obj>

From mb at bu3sch.de  Mon Feb 14 17:52:05 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Mon, 14 Feb 2011 23:52:05 +0100
Subject: Notes on ssb specs and implementation
In-Reply-To: <AANLkTi=ayavFKJw9s-n-AvMDrtMxXdDcjV+BnoxO-qkE@mail.gmail.com>
	(sfid-20110214_233217_829894_FFFFFFFFD1071FC3)
References: <AANLkTimfTt7kiwtSiPfE0kYRXwgHXJPAv19xuiv-M=NG@mail.gmail.com>
	<1297282621.9734.5.camel@maggie>
	<AANLkTinjDMSCqxWbAfjZO_JkfBZeRoAZOG5Pxvf1v8Xr@mail.gmail.com>
	<1297720877.5683.3.camel@maggie>
	<AANLkTi=ayavFKJw9s-n-AvMDrtMxXdDcjV+BnoxO-qkE@mail.gmail.com>
	(sfid-20110214_233217_829894_FFFFFFFFD1071FC3)
Message-ID: <1297723925.5683.11.camel@maggie>

On Mon, 2011-02-14 at 23:32 +0100, Rafa? Mi?ecki wrote: 
> Sure. It's not for submission, so you have to expect magic values.

That patch doesn't look too bad.

> Personally I don't like for example description at
> http://bcm-v4.sipsolutions.net/802.11/PHY . It's really messed in "Put
> PHY Into Reset".
> Section "Put PHY Into Reset" is really "How to reset PHY" and it
> duplicates code of takine PHY out of reset.

Yeah, well. Maybe I repeat myself for the hundredth time:
Do not duplicate the specifications exactly. Apply common sense before
implementing the code.
If we can do better on certain things, do it.

> We also have a lot of magic in ssb_device_enable. We reset SB and PHY
> at the same time. I guess it introduces some optimization but makes it
> harder to understand, especially if you try to understand implemented
> code and look as specs at the same time.

Well, it's core specific flags. I don't see anything
wrong here. I think the PHY reset might even require an actual core
reset to work correctly. So you could never untie both.
But that's exactly those magic things we're never going to find out
unless we have hardware documentation.

-- 
Greetings Michael.



From zajec5 at gmail.com  Mon Feb 14 18:02:54 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Tue, 15 Feb 2011 00:02:54 +0100
Subject: Notes on ssb specs and implementation
In-Reply-To: <1297723925.5683.11.camel@maggie>
References: <AANLkTimfTt7kiwtSiPfE0kYRXwgHXJPAv19xuiv-M=NG@mail.gmail.com>
	<1297282621.9734.5.camel@maggie>
	<AANLkTinjDMSCqxWbAfjZO_JkfBZeRoAZOG5Pxvf1v8Xr@mail.gmail.com>
	<1297720877.5683.3.camel@maggie>
	<AANLkTi=ayavFKJw9s-n-AvMDrtMxXdDcjV+BnoxO-qkE@mail.gmail.com>
	<1297723925.5683.11.camel@maggie>
Message-ID: <AANLkTinnY2EzNBReVPqHYzi9xDvZNXFZqbUm66e9vTOM@mail.gmail.com>

W dniu 14 lutego 2011 23:52 u?ytkownik Michael B?sch <mb at bu3sch.de> napisa?:
> On Mon, 2011-02-14 at 23:32 +0100, Rafa? Mi?ecki wrote:
>> Sure. It's not for submission, so you have to expect magic values.
>
> That patch doesn't look too bad.

Should we commit such a patch? Even if we didn't notice it to improve anything?

-- 
Rafa?


From mb at bu3sch.de  Mon Feb 14 18:08:33 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Tue, 15 Feb 2011 00:08:33 +0100
Subject: Notes on ssb specs and implementation
In-Reply-To: <AANLkTinnY2EzNBReVPqHYzi9xDvZNXFZqbUm66e9vTOM@mail.gmail.com>
	(sfid-20110215_000306_559821_FFFFFFFF9C6FCD67)
References: <AANLkTimfTt7kiwtSiPfE0kYRXwgHXJPAv19xuiv-M=NG@mail.gmail.com>
	<1297282621.9734.5.camel@maggie>
	<AANLkTinjDMSCqxWbAfjZO_JkfBZeRoAZOG5Pxvf1v8Xr@mail.gmail.com>
	<1297720877.5683.3.camel@maggie>
	<AANLkTi=ayavFKJw9s-n-AvMDrtMxXdDcjV+BnoxO-qkE@mail.gmail.com>
	<1297723925.5683.11.camel@maggie>
	<AANLkTinnY2EzNBReVPqHYzi9xDvZNXFZqbUm66e9vTOM@mail.gmail.com>
	(sfid-20110215_000306_559821_FFFFFFFF9C6FCD67)
Message-ID: <1297724913.5683.12.camel@maggie>

On Tue, 2011-02-15 at 00:02 +0100, Rafa? Mi?ecki wrote: 
> W dniu 14 lutego 2011 23:52 u?ytkownik Michael B?sch <mb at bu3sch.de> napisa?:
> > On Mon, 2011-02-14 at 23:32 +0100, Rafa? Mi?ecki wrote:
> >> Sure. It's not for submission, so you have to expect magic values.
> >
> > That patch doesn't look too bad.
> 
> Should we commit such a patch? Even if we didn't notice it to improve anything?

I think it should wait until you got the device working.
But once it works, it should be committed.

-- 
Greetings Michael.



From mb at bu3sch.de  Mon Feb 14 18:21:50 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Tue, 15 Feb 2011 00:21:50 +0100
Subject: [PATCH] ssb: Make ssb_wait_bit multi-bit safe
Message-ID: <1297725710.5683.17.camel@maggie>

ssb_wait_bit was designed for only one-bit bitmasks.
People start using it for multi-bit bitmasks. Make the "set" case
is safe for this. The "unset" case is already safe.

This does not change behavior of the current code.

Signed-off-by: Michael Buesch <mb at bu3sch.de>

---

Index: wireless-testing/drivers/ssb/main.c
===================================================================
--- wireless-testing.orig/drivers/ssb/main.c	2010-12-30 15:49:39.235946210 +0100
+++ wireless-testing/drivers/ssb/main.c	2011-02-15 00:17:35.727816704 +0100
@@ -1192,10 +1192,10 @@ void ssb_device_enable(struct ssb_device
 }
 EXPORT_SYMBOL(ssb_device_enable);
 
-/* Wait for a bit in a register to get set or unset.
+/* Wait for bitmask in a register to get set or cleared.
  * timeout is in units of ten-microseconds */
-static int ssb_wait_bit(struct ssb_device *dev, u16 reg, u32 bitmask,
-			int timeout, int set)
+static int ssb_wait_bits(struct ssb_device *dev, u16 reg, u32 bitmask,
+			 int timeout, int set)
 {
 	int i;
 	u32 val;
@@ -1203,7 +1203,7 @@ static int ssb_wait_bit(struct ssb_devic
 	for (i = 0; i < timeout; i++) {
 		val = ssb_read32(dev, reg);
 		if (set) {
-			if (val & bitmask)
+			if ((val & bitmask) == bitmask)
 				return 0;
 		} else {
 			if (!(val & bitmask))
@@ -1227,8 +1227,8 @@ void ssb_device_disable(struct ssb_devic
 
 	reject = ssb_tmslow_reject_bitmask(dev);
 	ssb_write32(dev, SSB_TMSLOW, reject | SSB_TMSLOW_CLOCK);
-	ssb_wait_bit(dev, SSB_TMSLOW, reject, 1000, 1);
-	ssb_wait_bit(dev, SSB_TMSHIGH, SSB_TMSHIGH_BUSY, 1000, 0);
+	ssb_wait_bits(dev, SSB_TMSLOW, reject, 1000, 1);
+	ssb_wait_bits(dev, SSB_TMSHIGH, SSB_TMSHIGH_BUSY, 1000, 0);
 	ssb_write32(dev, SSB_TMSLOW,
 		    SSB_TMSLOW_FGC | SSB_TMSLOW_CLOCK |
 		    reject | SSB_TMSLOW_RESET |

-- 
Greetings Michael.



From zajec5 at gmail.com  Mon Feb 14 18:44:58 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Tue, 15 Feb 2011 00:44:58 +0100
Subject: [PATCH] ssb: Make ssb_wait_bit multi-bit safe
In-Reply-To: <1297725710.5683.17.camel@maggie>
References: <1297725710.5683.17.camel@maggie>
Message-ID: <AANLkTimjkFJrWpubECRRNybmvYdcAh3UUbMOa0iv166g@mail.gmail.com>

2011/2/15 Michael B?sch <mb at bu3sch.de>:
> ssb_wait_bit was designed for only one-bit bitmasks.
> People start using it for multi-bit bitmasks. Make the "set" case
> is safe for this. The "unset" case is already safe.

Thanks :)

-- 
Rafa?


From mb at bu3sch.de  Mon Feb 14 18:59:29 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Tue, 15 Feb 2011 00:59:29 +0100
Subject: [PATCH] ssb: Make ssb_wait_bit multi-bit safe
In-Reply-To: <AANLkTimjkFJrWpubECRRNybmvYdcAh3UUbMOa0iv166g@mail.gmail.com>
	(sfid-20110215_004511_709733_4814F921)
References: <1297725710.5683.17.camel@maggie>
	<AANLkTimjkFJrWpubECRRNybmvYdcAh3UUbMOa0iv166g@mail.gmail.com>
	(sfid-20110215_004511_709733_4814F921)
Message-ID: <1297727969.5683.21.camel@maggie>

On Tue, 2011-02-15 at 00:44 +0100, Rafa? Mi?ecki wrote: 
> 2011/2/15 Michael B?sch <mb at bu3sch.de>:
> > ssb_wait_bit was designed for only one-bit bitmasks.
> > People start using it for multi-bit bitmasks. Make the "set" case
> > is safe for this. The "unset" case is already safe.
> 
> Thanks :)

This should not change the behavior of your patch, though,
as you only add an "unset" case, which was already correct.

So this doesn't fix an actual bug but rather hardens the code
for future use.

-- 
Greetings Michael.



From zajec5 at gmail.com  Mon Feb 14 19:04:36 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Tue, 15 Feb 2011 01:04:36 +0100
Subject: [PATCH] ssb: Make ssb_wait_bit multi-bit safe
In-Reply-To: <1297727969.5683.21.camel@maggie>
References: <1297725710.5683.17.camel@maggie>
	<AANLkTimjkFJrWpubECRRNybmvYdcAh3UUbMOa0iv166g@mail.gmail.com>
	<1297727969.5683.21.camel@maggie>
Message-ID: <AANLkTikQx_NTMxQ+XpL-3BKWkZMERs_A-aQf0mKBHaSg@mail.gmail.com>

W dniu 15 lutego 2011 00:59 u?ytkownik Michael B?sch <mb at bu3sch.de> napisa?:
> On Tue, 2011-02-15 at 00:44 +0100, Rafa? Mi?ecki wrote:
>> 2011/2/15 Michael B?sch <mb at bu3sch.de>:
>> > ssb_wait_bit was designed for only one-bit bitmasks.
>> > People start using it for multi-bit bitmasks. Make the "set" case
>> > is safe for this. The "unset" case is already safe.
>>
>> Thanks :)
>
> This should not change the behavior of your patch, though,
> as you only add an "unset" case, which was already correct.
>
> So this doesn't fix an actual bug but rather hardens the code
> for future use.

Yes, I can see that :)

-- 
Rafa?


From netrolller.3d at gmail.com  Mon Feb 14 19:03:33 2011
From: netrolller.3d at gmail.com (=?ISO-8859-1?Q?G=E1bor_Stefanik?=)
Date: Tue, 15 Feb 2011 01:03:33 +0100
Subject: [PATCH] ssb: Make ssb_wait_bit multi-bit safe
In-Reply-To: <1297725710.5683.17.camel@maggie>
References: <1297725710.5683.17.camel@maggie>
Message-ID: <AANLkTingds9m3sj5bJoExiuoivbRSAtnF2A-4emjYMdJ@mail.gmail.com>

On Tue, Feb 15, 2011 at 12:21 AM, Michael B?sch <mb at bu3sch.de> wrote:
> ssb_wait_bit was designed for only one-bit bitmasks.
> People start using it for multi-bit bitmasks. Make the "set" case
> is safe for this. The "unset" case is already safe.
>
> This does not change behavior of the current code.
>
> Signed-off-by: Michael Buesch <mb at bu3sch.de>
>
> ---
>
> Index: wireless-testing/drivers/ssb/main.c
> ===================================================================
> --- wireless-testing.orig/drivers/ssb/main.c ? ?2010-12-30 15:49:39.235946210 +0100
> +++ wireless-testing/drivers/ssb/main.c 2011-02-15 00:17:35.727816704 +0100
> @@ -1192,10 +1192,10 @@ void ssb_device_enable(struct ssb_device
> ?}
> ?EXPORT_SYMBOL(ssb_device_enable);
>
> -/* Wait for a bit in a register to get set or unset.
> +/* Wait for bitmask in a register to get set or cleared.
> ?* timeout is in units of ten-microseconds */
> -static int ssb_wait_bit(struct ssb_device *dev, u16 reg, u32 bitmask,
> - ? ? ? ? ? ? ? ? ? ? ? int timeout, int set)
> +static int ssb_wait_bits(struct ssb_device *dev, u16 reg, u32 bitmask,
> + ? ? ? ? ? ? ? ? ? ? ? ?int timeout, int set)

While you are at it, you may want to change this to "bool set".

> ?{
> ? ? ? ?int i;
> ? ? ? ?u32 val;
> @@ -1203,7 +1203,7 @@ static int ssb_wait_bit(struct ssb_devic
> ? ? ? ?for (i = 0; i < timeout; i++) {
> ? ? ? ? ? ? ? ?val = ssb_read32(dev, reg);
> ? ? ? ? ? ? ? ?if (set) {
> - ? ? ? ? ? ? ? ? ? ? ? if (val & bitmask)
> + ? ? ? ? ? ? ? ? ? ? ? if ((val & bitmask) == bitmask)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?return 0;
> ? ? ? ? ? ? ? ?} else {
> ? ? ? ? ? ? ? ? ? ? ? ?if (!(val & bitmask))
> @@ -1227,8 +1227,8 @@ void ssb_device_disable(struct ssb_devic
>
> ? ? ? ?reject = ssb_tmslow_reject_bitmask(dev);
> ? ? ? ?ssb_write32(dev, SSB_TMSLOW, reject | SSB_TMSLOW_CLOCK);
> - ? ? ? ssb_wait_bit(dev, SSB_TMSLOW, reject, 1000, 1);
> - ? ? ? ssb_wait_bit(dev, SSB_TMSHIGH, SSB_TMSHIGH_BUSY, 1000, 0);
> + ? ? ? ssb_wait_bits(dev, SSB_TMSLOW, reject, 1000, 1);
> + ? ? ? ssb_wait_bits(dev, SSB_TMSHIGH, SSB_TMSHIGH_BUSY, 1000, 0);
> ? ? ? ?ssb_write32(dev, SSB_TMSLOW,
> ? ? ? ? ? ? ? ? ? ?SSB_TMSLOW_FGC | SSB_TMSLOW_CLOCK |
> ? ? ? ? ? ? ? ? ? ?reject | SSB_TMSLOW_RESET |
>
> --
> Greetings Michael.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)


From mb at bu3sch.de  Mon Feb 14 19:20:01 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Tue, 15 Feb 2011 01:20:01 +0100
Subject: [PATCH] ssb: Make ssb_wait_bit multi-bit safe
In-Reply-To: <AANLkTingds9m3sj5bJoExiuoivbRSAtnF2A-4emjYMdJ@mail.gmail.com>
	(sfid-20110215_011145_942850_24C2EA9B)
References: <1297725710.5683.17.camel@maggie>
	<AANLkTingds9m3sj5bJoExiuoivbRSAtnF2A-4emjYMdJ@mail.gmail.com>
	(sfid-20110215_011145_942850_24C2EA9B)
Message-ID: <1297729201.5683.22.camel@maggie>

On Tue, 2011-02-15 at 01:03 +0100, G?bor Stefanik wrote: 
> > -static int ssb_wait_bit(struct ssb_device *dev, u16 reg, u32 bitmask,
> > -                       int timeout, int set)
> > +static int ssb_wait_bits(struct ssb_device *dev, u16 reg, u32 bitmask,
> > +                        int timeout, int set)
> 
> While you are at it, you may want to change this to "bool set".

Please feel free to submit a separate patch on top of this.

-- 
Greetings Michael.



From zajec5 at gmail.com  Wed Feb 16 07:58:25 2011
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Wed, 16 Feb 2011 13:58:25 +0100
Subject: [PATCH 1/2] ssb: trivial: fix SPROM extract warning formatting
Message-ID: <1297861106-18739-1-git-send-email-zajec5@gmail.com>

Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>
---
 drivers/ssb/pci.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/ssb/pci.c b/drivers/ssb/pci.c
index 158449e..127897c 100644
--- a/drivers/ssb/pci.c
+++ b/drivers/ssb/pci.c
@@ -641,7 +641,7 @@ static int sprom_extract(struct ssb_bus *bus, struct ssb_sprom *out,
 		break;
 	default:
 		ssb_printk(KERN_WARNING PFX "Unsupported SPROM"
-			   "  revision %d detected. Will extract"
+			   " revision %d detected. Will extract"
 			   " v1\n", out->revision);
 		out->revision = 1;
 		sprom_extract_r123(out, in);
-- 
1.7.1



From zajec5 at gmail.com  Wed Feb 16 07:58:26 2011
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Wed, 16 Feb 2011 13:58:26 +0100
Subject: [PATCH 2/2] ssb: remove invalid define SSB_TMSLOW_PHYCLK
In-Reply-To: <1297861106-18739-1-git-send-email-zajec5@gmail.com>
References: <1297861106-18739-1-git-send-email-zajec5@gmail.com>
Message-ID: <1297861106-18739-2-git-send-email-zajec5@gmail.com>

It was incorrectly introduced in d2730b2a6a019d14455556019d744ab051e6554b. We
have already fixed function to use correct define, but forgot remove old one.

Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>
Cc: G?bor Stefanik <netrolller.3d at gmail.com>
---
 include/linux/ssb/ssb_regs.h |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/include/linux/ssb/ssb_regs.h b/include/linux/ssb/ssb_regs.h
index 489f7b6..01253c6 100644
--- a/include/linux/ssb/ssb_regs.h
+++ b/include/linux/ssb/ssb_regs.h
@@ -97,7 +97,6 @@
 #define  SSB_TMSLOW_RESET	0x00000001 /* Reset */
 #define  SSB_TMSLOW_REJECT_22	0x00000002 /* Reject (Backplane rev 2.2) */
 #define  SSB_TMSLOW_REJECT_23	0x00000004 /* Reject (Backplane rev 2.3) */
-#define  SSB_TMSLOW_PHYCLK	0x00000010 /* MAC PHY Clock Control Enable */
 #define  SSB_TMSLOW_CLOCK	0x00010000 /* Clock Enable */
 #define  SSB_TMSLOW_FGC		0x00020000 /* Force Gated Clocks On */
 #define  SSB_TMSLOW_PE		0x40000000 /* Power Management Enable */
-- 
1.7.1



From zajec5 at gmail.com  Wed Feb 16 08:13:32 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Wed, 16 Feb 2011 14:13:32 +0100
Subject: [RFC] How to rename SSB_TMSLOW_*, B43_TMSLOW_*?
Message-ID: <AANLkTimKE+WqChVf0XpeHsfHxT8=3vbnBh=Lo+1tLSwj@mail.gmail.com>

Except for following 3 defines:
#define  SSB_TMSLOW_RESET	0x00000001 /* Reset */
#define  SSB_TMSLOW_REJECT_22	0x00000002 /* Reject (Backplane rev 2.2) */
#define  SSB_TMSLOW_REJECT_23	0x00000004 /* Reject (Backplane rev 2.3) */

All our SSB_TMSLOW_* and B43_TMSLOW_* defines are some core control
bits. As we now know, core control bits are not SSB specific or TMSLOW
specific.

Should we (and how) define that names in this situation?

For b43 I propose (quite obvious?) B43_CORE_CTL_*.

However what about SSB_TMSLOW_*? George proposed SSB_CORECTL_*, but it
contains "SSB", while that bits are not SSB specific. Same bits are
used on AI bus. Should we use some SSBAI_CORE_CTL_* then? Any other
ideas? Some better maybe?

P.S.
Personally I prefer CORE_CTL over CORECTL (George). Which one should we use?

-- 
Rafa?


From pedrazaa at yahoo.com  Wed Feb 16 12:52:17 2011
From: pedrazaa at yahoo.com (Ariel Pedraza)
Date: Wed, 16 Feb 2011 09:52:17 -0800 (PST)
Subject: brcm80211 monitor mode support
Message-ID: <778785.1687.qm@web111415.mail.gq1.yahoo.com>

Who knows when the brcm80211 driver will support monitor mode?

To Be Done
    * Add support for
          o monitor mode



      


From mb at bu3sch.de  Wed Feb 16 17:17:37 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Wed, 16 Feb 2011 23:17:37 +0100
Subject: [RFC] How to rename SSB_TMSLOW_*, B43_TMSLOW_*?
In-Reply-To: <AANLkTimKE+WqChVf0XpeHsfHxT8=3vbnBh=Lo+1tLSwj@mail.gmail.com>
	(sfid-20110216_141342_431478_3C8E43BA)
References: <AANLkTimKE+WqChVf0XpeHsfHxT8=3vbnBh=Lo+1tLSwj@mail.gmail.com>
	(sfid-20110216_141342_431478_3C8E43BA)
Message-ID: <1297894657.32237.2.camel@maggie>

On Wed, 2011-02-16 at 14:13 +0100, Rafa? Mi?ecki wrote: 
> Except for following 3 defines:
> #define  SSB_TMSLOW_RESET	0x00000001 /* Reset */
> #define  SSB_TMSLOW_REJECT_22	0x00000002 /* Reject (Backplane rev 2.2) */
> #define  SSB_TMSLOW_REJECT_23	0x00000004 /* Reject (Backplane rev 2.3) */
> 
> All our SSB_TMSLOW_* and B43_TMSLOW_* defines are some core control
> bits. As we now know, core control bits are not SSB specific or TMSLOW
> specific.
> 
> Should we (and how) define that names in this situation?
> 
> For b43 I propose (quite obvious?) B43_CORE_CTL_*.
> 
> However what about SSB_TMSLOW_*? George proposed SSB_CORECTL_*, but it
> contains "SSB", while that bits are not SSB specific. Same bits are
> used on AI bus. Should we use some SSBAI_CORE_CTL_* then? Any other
> ideas? Some better maybe?
> 
> P.S.
> Personally I prefer CORE_CTL over CORECTL (George). Which one should we use?

Let's simply put those bits into the drivers and call them
DRIVERNAME_TMSLOW_FOOBAR

The "TMSLOW" part seems rather important to me, because that makes it
obvious what register these bits belong to. Note that's there's also
TMSHIGH. It also follows current naming convention.

-- 
Greetings Michael.



From mb at bu3sch.de  Wed Feb 16 17:20:56 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Wed, 16 Feb 2011 23:20:56 +0100
Subject: [PATCH 1/2] ssb: trivial: fix SPROM extract warning formatting
In-Reply-To: <1297861106-18739-1-git-send-email-zajec5@gmail.com>
	(sfid-20110216_135811_600712_6253D5CA)
References: <1297861106-18739-1-git-send-email-zajec5@gmail.com>
	(sfid-20110216_135811_600712_6253D5CA)
Message-ID: <1297894856.32237.5.camel@maggie>

On Wed, 2011-02-16 at 13:58 +0100, Rafa? Mi?ecki wrote: 
> Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>
> ---
>  drivers/ssb/pci.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/ssb/pci.c b/drivers/ssb/pci.c
> index 158449e..127897c 100644
> --- a/drivers/ssb/pci.c
> +++ b/drivers/ssb/pci.c
> @@ -641,7 +641,7 @@ static int sprom_extract(struct ssb_bus *bus, struct ssb_sprom *out,
>  		break;
>  	default:
>  		ssb_printk(KERN_WARNING PFX "Unsupported SPROM"
> -			   "  revision %d detected. Will extract"
> +			   " revision %d detected. Will extract"
>  			   " v1\n", out->revision);
>  		out->revision = 1;
>  		sprom_extract_r123(out, in);

ack for those two patches.

-- 
Greetings Michael.



From zajec5 at gmail.com  Wed Feb 16 19:50:49 2011
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Thu, 17 Feb 2011 01:50:49 +0100
Subject: [PATCH 0/2] ssb: improve device disabling
Message-ID: <1297903851-5499-1-git-send-email-zajec5@gmail.com>

With that patches we follow specs and (as recently proved by MMIO dumps) wl.

The more important patch is the first one. It detects problem (and warns) with
SSB when it is in some broken state. We can for example hit such an issue when
enabling DMA on 14e4:4329 (N-PHY, rev 1). The real fix is now known yet, but
not we at least get warning. Switching to PIO on that card does not raise
warning anymore (as expected).

We all hate regressions and Michal says than enabling/disabling SSB device can
be tricky. I have tested that patches with few b43 driven devices:
14e4:4318 (BCM4318)
14e4:4315 (BCM4312)
14e4:4329 (BCM4321)
14e4:4328 (BCM4321)
14e4:432b (BCM4322)

With each device I performed cold booting, loading b43, testing, bringing
interface down and up, testing, reloading, testing. Sometime even more.

Unfortunately I do not have aany other SSB devices, like that supported by b44
or gige (OK, I did not even hear about gige earlier).

Rafa? Mi?ecki (2):
  ssb: when needed, reject IM input while disabling device
  ssb: reset device only if it was enabled

 drivers/ssb/main.c           |   36 +++++++++++++++++++++++++++---------
 include/linux/ssb/ssb_regs.h |    2 ++
 2 files changed, 29 insertions(+), 9 deletions(-)

-- 
1.7.3.4



From zajec5 at gmail.com  Wed Feb 16 19:50:50 2011
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Thu, 17 Feb 2011 01:50:50 +0100
Subject: [PATCH 1/2] ssb: when needed, reject IM input while disabling device
In-Reply-To: <1297903851-5499-1-git-send-email-zajec5@gmail.com>
References: <1297903851-5499-1-git-send-email-zajec5@gmail.com>
Message-ID: <1297903851-5499-2-git-send-email-zajec5@gmail.com>

Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>
---
 drivers/ssb/main.c           |   16 +++++++++++++++-
 include/linux/ssb/ssb_regs.h |    2 ++
 2 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
index 08fed55..5b6160a 100644
--- a/drivers/ssb/main.c
+++ b/drivers/ssb/main.c
@@ -1220,7 +1220,7 @@ static int ssb_wait_bits(struct ssb_device *dev, u16 reg, u32 bitmask,
 
 void ssb_device_disable(struct ssb_device *dev, u32 core_specific_flags)
 {
-	u32 reject;
+	u32 reject, val;
 
 	if (ssb_read32(dev, SSB_TMSLOW) & SSB_TMSLOW_RESET)
 		return;
@@ -1229,12 +1229,26 @@ void ssb_device_disable(struct ssb_device *dev, u32 core_specific_flags)
 	ssb_write32(dev, SSB_TMSLOW, reject | SSB_TMSLOW_CLOCK);
 	ssb_wait_bits(dev, SSB_TMSLOW, reject, 1000, 1);
 	ssb_wait_bits(dev, SSB_TMSHIGH, SSB_TMSHIGH_BUSY, 1000, 0);
+
+	if (ssb_read32(dev, SSB_IDLOW) & SSB_IDLOW_INITIATOR) {
+		val = ssb_read32(dev, SSB_IMSTATE);
+		val |= SSB_IMSTATE_REJECT;
+		ssb_write32(dev, SSB_IMSTATE, val);
+		ssb_wait_bits(dev, SSB_IMSTATE, SSB_IMSTATE_BUSY, 1000, 0);
+	}
+
 	ssb_write32(dev, SSB_TMSLOW,
 		    SSB_TMSLOW_FGC | SSB_TMSLOW_CLOCK |
 		    reject | SSB_TMSLOW_RESET |
 		    core_specific_flags);
 	ssb_flush_tmslow(dev);
 
+	if (ssb_read32(dev, SSB_IDLOW) & SSB_IDLOW_INITIATOR) {
+		val = ssb_read32(dev, SSB_IMSTATE);
+		val &= ~SSB_IMSTATE_REJECT;
+		ssb_write32(dev, SSB_IMSTATE, val);
+	}
+
 	ssb_write32(dev, SSB_TMSLOW,
 		    reject | SSB_TMSLOW_RESET |
 		    core_specific_flags);
diff --git a/include/linux/ssb/ssb_regs.h b/include/linux/ssb/ssb_regs.h
index 489f7b6..8ac6346 100644
--- a/include/linux/ssb/ssb_regs.h
+++ b/include/linux/ssb/ssb_regs.h
@@ -85,6 +85,8 @@
 #define  SSB_IMSTATE_AP_RSV	0x00000030 /* Reserved */
 #define  SSB_IMSTATE_IBE	0x00020000 /* In Band Error */
 #define  SSB_IMSTATE_TO		0x00040000 /* Timeout */
+#define  SSB_IMSTATE_BUSY	0x01800000 /* Busy (Backplane rev >= 2.3 only) */
+#define  SSB_IMSTATE_REJECT	0x02000000 /* Reject (Backplane rev >= 2.3 only) */
 #define SSB_INTVEC		0x0F94     /* SB Interrupt Mask */
 #define  SSB_INTVEC_PCI		0x00000001 /* Enable interrupts for PCI */
 #define  SSB_INTVEC_ENET0	0x00000002 /* Enable interrupts for enet 0 */
-- 
1.7.3.4



From zajec5 at gmail.com  Wed Feb 16 19:50:51 2011
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Thu, 17 Feb 2011 01:50:51 +0100
Subject: [PATCH 2/2] ssb: reset device only if it was enabled
In-Reply-To: <1297903851-5499-1-git-send-email-zajec5@gmail.com>
References: <1297903851-5499-1-git-send-email-zajec5@gmail.com>
Message-ID: <1297903851-5499-3-git-send-email-zajec5@gmail.com>

Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>
---
 drivers/ssb/main.c |   40 ++++++++++++++++++++++------------------
 1 files changed, 22 insertions(+), 18 deletions(-)

diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
index 5b6160a..0c1c43a 100644
--- a/drivers/ssb/main.c
+++ b/drivers/ssb/main.c
@@ -1226,27 +1226,31 @@ void ssb_device_disable(struct ssb_device *dev, u32 core_specific_flags)
 		return;
 
 	reject = ssb_tmslow_reject_bitmask(dev);
-	ssb_write32(dev, SSB_TMSLOW, reject | SSB_TMSLOW_CLOCK);
-	ssb_wait_bits(dev, SSB_TMSLOW, reject, 1000, 1);
-	ssb_wait_bits(dev, SSB_TMSHIGH, SSB_TMSHIGH_BUSY, 1000, 0);
 
-	if (ssb_read32(dev, SSB_IDLOW) & SSB_IDLOW_INITIATOR) {
-		val = ssb_read32(dev, SSB_IMSTATE);
-		val |= SSB_IMSTATE_REJECT;
-		ssb_write32(dev, SSB_IMSTATE, val);
-		ssb_wait_bits(dev, SSB_IMSTATE, SSB_IMSTATE_BUSY, 1000, 0);
-	}
+	if (ssb_read32(dev, SSB_TMSLOW) & SSB_TMSLOW_CLOCK) {
+		ssb_write32(dev, SSB_TMSLOW, reject | SSB_TMSLOW_CLOCK);
+		ssb_wait_bits(dev, SSB_TMSLOW, reject, 1000, 1);
+		ssb_wait_bits(dev, SSB_TMSHIGH, SSB_TMSHIGH_BUSY, 1000, 0);
+
+		if (ssb_read32(dev, SSB_IDLOW) & SSB_IDLOW_INITIATOR) {
+			val = ssb_read32(dev, SSB_IMSTATE);
+			val |= SSB_IMSTATE_REJECT;
+			ssb_write32(dev, SSB_IMSTATE, val);
+			ssb_wait_bits(dev, SSB_IMSTATE, SSB_IMSTATE_BUSY, 1000,
+				      0);
+		}
 
-	ssb_write32(dev, SSB_TMSLOW,
-		    SSB_TMSLOW_FGC | SSB_TMSLOW_CLOCK |
-		    reject | SSB_TMSLOW_RESET |
-		    core_specific_flags);
-	ssb_flush_tmslow(dev);
+		ssb_write32(dev, SSB_TMSLOW,
+			SSB_TMSLOW_FGC | SSB_TMSLOW_CLOCK |
+			reject | SSB_TMSLOW_RESET |
+			core_specific_flags);
+		ssb_flush_tmslow(dev);
 
-	if (ssb_read32(dev, SSB_IDLOW) & SSB_IDLOW_INITIATOR) {
-		val = ssb_read32(dev, SSB_IMSTATE);
-		val &= ~SSB_IMSTATE_REJECT;
-		ssb_write32(dev, SSB_IMSTATE, val);
+		if (ssb_read32(dev, SSB_IDLOW) & SSB_IDLOW_INITIATOR) {
+			val = ssb_read32(dev, SSB_IMSTATE);
+			val &= ~SSB_IMSTATE_REJECT;
+			ssb_write32(dev, SSB_IMSTATE, val);
+		}
 	}
 
 	ssb_write32(dev, SSB_TMSLOW,
-- 
1.7.3.4



From Larry.Finger at lwfinger.net  Wed Feb 16 23:21:52 2011
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Wed, 16 Feb 2011 22:21:52 -0600
Subject: [PATCH 0/2] ssb: improve device disabling
In-Reply-To: <1297903851-5499-1-git-send-email-zajec5@gmail.com>
References: <1297903851-5499-1-git-send-email-zajec5@gmail.com>
Message-ID: <4D5CA260.1070807@lwfinger.net>

On 02/16/2011 06:50 PM, Rafa? Mi?ecki wrote:
> With that patches we follow specs and (as recently proved by MMIO dumps) wl.
>
> The more important patch is the first one. It detects problem (and warns) with
> SSB when it is in some broken state. We can for example hit such an issue when
> enabling DMA on 14e4:4329 (N-PHY, rev 1). The real fix is now known yet, but
> not we at least get warning. Switching to PIO on that card does not raise
> warning anymore (as expected).
>
> We all hate regressions and Michal says than enabling/disabling SSB device can
> be tricky. I have tested that patches with few b43 driven devices:
> 14e4:4318 (BCM4318)
> 14e4:4315 (BCM4312)
> 14e4:4329 (BCM4321)
> 14e4:4328 (BCM4321)
> 14e4:432b (BCM4322)

I tested 14e4:4311 (BCM4311) and found no problems.

Larry


From zajec5 at gmail.com  Thu Feb 17 07:14:21 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Thu, 17 Feb 2011 13:14:21 +0100
Subject: [RFC] How to rename SSB_TMSLOW_*, B43_TMSLOW_*?
In-Reply-To: <1297894657.32237.2.camel@maggie>
References: <AANLkTimKE+WqChVf0XpeHsfHxT8=3vbnBh=Lo+1tLSwj@mail.gmail.com>
	<1297894657.32237.2.camel@maggie>
Message-ID: <AANLkTi=sVaeizU3xJQQwwKXB5saPgdn9VxNQv0-aoiV7@mail.gmail.com>

W dniu 16 lutego 2011 23:17 u?ytkownik Michael B?sch <mb at bu3sch.de> napisa?:
> On Wed, 2011-02-16 at 14:13 +0100, Rafa? Mi?ecki wrote:
>> Except for following 3 defines:
>> #define ?SSB_TMSLOW_RESET ? ? 0x00000001 /* Reset */
>> #define ?SSB_TMSLOW_REJECT_22 0x00000002 /* Reject (Backplane rev 2.2) */
>> #define ?SSB_TMSLOW_REJECT_23 0x00000004 /* Reject (Backplane rev 2.3) */
>>
>> All our SSB_TMSLOW_* and B43_TMSLOW_* defines are some core control
>> bits. As we now know, core control bits are not SSB specific or TMSLOW
>> specific.
>>
>> Should we (and how) define that names in this situation?
>>
>> For b43 I propose (quite obvious?) B43_CORE_CTL_*.
>>
>> However what about SSB_TMSLOW_*? George proposed SSB_CORECTL_*, but it
>> contains "SSB", while that bits are not SSB specific. Same bits are
>> used on AI bus. Should we use some SSBAI_CORE_CTL_* then? Any other
>> ideas? Some better maybe?
>>
>> P.S.
>> Personally I prefer CORE_CTL over CORECTL (George). Which one should we use?
>
> Let's simply put those bits into the drivers and call them
> DRIVERNAME_TMSLOW_FOOBAR

That's what we already have...
B43_TMSLOW_GMODE
B43_TMSLOW_PLLREFSEL
B43_TMSLOW_MACPHYCLKEN
B43_TMSLOW_PHYRESET
B43_TMSLOW_PHYCLKEN
And it's fine for now, but not if we want to have AI support in b43.
See my next comment.


> The "TMSLOW" part seems rather important to me, because that makes it
> obvious what register these bits belong to. Note that's there's also
> TMSHIGH. It also follows current naming convention.

I skip TMSHIGH for now, to simplify discussion.

Your proposal is fine as long as we use that flags for TMSLOW only.
But we may need to use that for AI boards in future, which does not
contain TMSLOW. So that way we would finish with something so ugly:

#define B43_SSB_TMSLOW_GMODE			0x20000000	/* G Mode Enable */
#define B43_SSB_TMSLOW_PHY_BANDWIDTH		0x00C00000	/* PHY band width and
clock speed mask (N-PHY only) */
#define  B43_SSB_TMSLOW_PHY_BANDWIDTH_10MHZ	0x00000000	/* 10 MHz
bandwidth, 40 MHz PHY */
#define  B43_SSB_TMSLOW_PHY_BANDWIDTH_20MHZ	0x00400000	/* 20 MHz
bandwidth, 80 MHz PHY */
#define  B43_SSB_TMSLOW_PHY_BANDWIDTH_40MHZ	0x00800000	/* 40 MHz
bandwidth, 160 MHz PHY */
#define B43_SSB_TMSLOW_PLLREFSEL		0x00200000	/* PLL Frequency
Reference Select (rev >= 5) */
#define B43_SSB_TMSLOW_MACPHYCLKEN		0x00100000	/* MAC PHY Clock
Control Enable (rev >= 5) */
#define B43_SSB_TMSLOW_PHYRESET			0x00080000	/* PHY Reset */
#define B43_SSB_TMSLOW_PHYCLKEN			0x00040000	/* PHY Clock Enable */

#define B43_AI_REGNAME_GMODE			0x2000	/* G Mode Enable */
#define B43_AI_REGNAME_BANDWIDTH		0x00C0	/* PHY band width and clock
speed mask (N-PHY only) */
#define  B43_AI_REGNAME_BANDWIDTH_10MHZ		0x0000	/* 10 MHz bandwidth,
40 MHz PHY */
#define  B43_AI_REGNAME_BANDWIDTH_20MHZ		0x0040	/* 20 MHz bandwidth,
80 MHz PHY */
#define  B43_AI_REGNAME_BANDWIDTH_40MHZ		0x0080	/* 40 MHz bandwidth,
160 MHz PHY */
#define B43_AI_REGNAME_PLLREFSEL		0x0020	/* PLL Frequency Reference
Select (rev >= 5) */
#define B43_AI_REGNAME_MACPHYCLKEN		0x0010	/* MAC PHY Clock Control
Enable (rev >= 5) */
#define B43_AI_REGNAME_RESET			0x0008	/* PHY Reset */
#define B43_AI_REGNAME_CLKEN			0x0004	/* PHY Clock Enable */

if (boardtype == SSB) {
	flags |= B43_SSB_TMSLOW_PHYCLKEN;
	flags |= B43_SSB_TMSLOW_PHYRESET;
	if (dev->phy.type == B43_PHYTYPE_N)
		flags |= B43_SSB_TMSLOW_PHY_BANDWIDTH_20MHZ; /* Make 20 MHz def */
} else if (boardtype == AI) {
	flags |= B43_AI_REGNAME_PHYCLKEN;
	flags |= B43_AI_REGNAME_PHYRESET;
	if (dev->phy.type == B43_PHYTYPE_N)
		flags |= B43_AI_REGNAME_PHY_BANDWIDTH_20MHZ; /* Make 20 MHz def */
}

That's why I wanted to introduce some SSBAI_CORECTL_FOOBAR and make
b43 unaware it that flags are going to be written in register A or B.
I wanted b43 to just pass flags to correct function and do not care
about place where they are getting written.

-- 
Rafa?
-------------- next part --------------
#define B43_SSB_TMSLOW_GMODE			0x20000000	/* G Mode Enable */
#define B43_SSB_TMSLOW_PHY_BANDWIDTH		0x00C00000	/* PHY band width and clock speed mask (N-PHY only) */
#define  B43_SSB_TMSLOW_PHY_BANDWIDTH_10MHZ	0x00000000	/* 10 MHz bandwidth, 40 MHz PHY */
#define  B43_SSB_TMSLOW_PHY_BANDWIDTH_20MHZ	0x00400000	/* 20 MHz bandwidth, 80 MHz PHY */
#define  B43_SSB_TMSLOW_PHY_BANDWIDTH_40MHZ	0x00800000	/* 40 MHz bandwidth, 160 MHz PHY */
#define B43_SSB_TMSLOW_PLLREFSEL		0x00200000	/* PLL Frequency Reference Select (rev >= 5) */
#define B43_SSB_TMSLOW_MACPHYCLKEN		0x00100000	/* MAC PHY Clock Control Enable (rev >= 5) */
#define B43_SSB_TMSLOW_PHYRESET			0x00080000	/* PHY Reset */
#define B43_SSB_TMSLOW_PHYCLKEN			0x00040000	/* PHY Clock Enable */

#define B43_AI_REGNAME_GMODE			0x2000	/* G Mode Enable */
#define B43_AI_REGNAME_BANDWIDTH		0x00C0	/* PHY band width and clock speed mask (N-PHY only) */
#define  B43_AI_REGNAME_BANDWIDTH_10MHZ		0x0000	/* 10 MHz bandwidth, 40 MHz PHY */
#define  B43_AI_REGNAME_BANDWIDTH_20MHZ		0x0040	/* 20 MHz bandwidth, 80 MHz PHY */
#define  B43_AI_REGNAME_BANDWIDTH_40MHZ		0x0080	/* 40 MHz bandwidth, 160 MHz PHY */
#define B43_AI_REGNAME_PLLREFSEL		0x0020	/* PLL Frequency Reference Select (rev >= 5) */
#define B43_AI_REGNAME_MACPHYCLKEN		0x0010	/* MAC PHY Clock Control Enable (rev >= 5) */
#define B43_AI_REGNAME_RESET			0x0008	/* PHY Reset */
#define B43_AI_REGNAME_CLKEN			0x0004	/* PHY Clock Enable */

if (boardtype == SSB) {
	flags |= B43_SSB_TMSLOW_PHYCLKEN;
	flags |= B43_SSB_TMSLOW_PHYRESET;
	if (dev->phy.type == B43_PHYTYPE_N)
		flags |= B43_SSB_TMSLOW_PHY_BANDWIDTH_20MHZ; /* Make 20 MHz def */
} else if (boardtype == AI) {
	flags |= B43_AI_REGNAME_PHYCLKEN;
	flags |= B43_AI_REGNAME_PHYRESET;
	if (dev->phy.type == B43_PHYTYPE_N)
		flags |= B43_AI_REGNAME_PHY_BANDWIDTH_20MHZ; /* Make 20 MHz def */
}

From mb at bu3sch.de  Thu Feb 17 17:00:18 2011
From: mb at bu3sch.de (Michael =?ISO-8859-1?Q?B=FCsch?=)
Date: Thu, 17 Feb 2011 23:00:18 +0100
Subject: [RFC] How to rename SSB_TMSLOW_*, B43_TMSLOW_*?
In-Reply-To: <AANLkTi=sVaeizU3xJQQwwKXB5saPgdn9VxNQv0-aoiV7@mail.gmail.com>
	(sfid-20110217_131436_086343_78318A6B)
References: <AANLkTimKE+WqChVf0XpeHsfHxT8=3vbnBh=Lo+1tLSwj@mail.gmail.com>
	<1297894657.32237.2.camel@maggie>
	<AANLkTi=sVaeizU3xJQQwwKXB5saPgdn9VxNQv0-aoiV7@mail.gmail.com>
	(sfid-20110217_131436_086343_78318A6B)
Message-ID: <1297980018.13554.4.camel@maggie>

On Thu, 2011-02-17 at 13:14 +0100, Rafa? Mi?ecki wrote: 
> That's why I wanted to introduce some SSBAI_CORECTL_FOOBAR and make
> b43 unaware it that flags are going to be written in register A or B.
> I wanted b43 to just pass flags to correct function and do not care
> about place where they are getting written.

Ok, well. That's basically what I am talking about for several
days now.

1) Keep SSB and AI separated.
2) Introduce an additional thin layer on top of this to abstract the
bus to the drivers.

-- 
Greetings Michael.



From zajec5 at gmail.com  Thu Feb 17 17:15:18 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Thu, 17 Feb 2011 23:15:18 +0100
Subject: [RFC] How to rename SSB_TMSLOW_*, B43_TMSLOW_*?
In-Reply-To: <1297980018.13554.4.camel@maggie>
References: <AANLkTimKE+WqChVf0XpeHsfHxT8=3vbnBh=Lo+1tLSwj@mail.gmail.com>
	<1297894657.32237.2.camel@maggie>
	<AANLkTi=sVaeizU3xJQQwwKXB5saPgdn9VxNQv0-aoiV7@mail.gmail.com>
	<1297980018.13554.4.camel@maggie>
Message-ID: <AANLkTi=FYOTt=8bMmH6W5Noeuifd-h9t8HEZB9ovg5ic@mail.gmail.com>

W dniu 17 lutego 2011 23:00 u?ytkownik Michael B?sch <mb at bu3sch.de> napisa?:
> On Thu, 2011-02-17 at 13:14 +0100, Rafa? Mi?ecki wrote:
>> That's why I wanted to introduce some SSBAI_CORECTL_FOOBAR and make
>> b43 unaware it that flags are going to be written in register A or B.
>> I wanted b43 to just pass flags to correct function and do not care
>> about place where they are getting written.
>
> Ok, well. That's basically what I am talking about for several
> days now.
>
> 1) Keep SSB and AI separated.
> 2) Introduce an additional thin layer on top of this to abstract the
> bus to the drivers.

OK, but how do you see core flags implemented in such a layout? The
ugly way I proposed seems to match your idea but... is ugly.

Can you say sth more about that? What about such a shared things that
differs in a minimal way?

-- 
Rafa?


From zajec5 at gmail.com  Fri Feb 18 16:24:00 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Fri, 18 Feb 2011 22:24:00 +0100
Subject: Request for free-distributable Broadcom's (G|LP)-PHY firmware
In-Reply-To: <1287674517.2383.7.camel@dcbw.foobar.com>
References: <AANLkTik45KLdLf5UpjPtXTNgy4Df_BupyQ3SzRr6gZgC@mail.gmail.com>
	<AANLkTin_JcEyT21dTS=Ew868HJvZQ2FVZBGXjCZn=8O_@mail.gmail.com>
	<4CBF640C.4080405@broadcom.com>
	<AANLkTinfwhjvfJU6C97SPJ8YKRqyJaCoQnAcC_uKLZa=@mail.gmail.com>
	<1287674517.2383.7.camel@dcbw.foobar.com>
Message-ID: <AANLkTikLbtV5dLu+Gu=8ibi=ERPiOykN9qBL4rPKS36g@mail.gmail.com>

W dniu 21 pa?dziernika 2010 17:21 u?ytkownik Dan Williams
<dcbw at redhat.com> napisa?:
> On Thu, 2010-10-21 at 00:11 +0200, Rafa? Mi?ecki wrote:
>> W dniu 20 pa?dziernika 2010 23:50 u?ytkownik Henry Ptasinski
>> <henryp at broadcom.com> napisa?:
>> > Sorry for the delay in responding. ?We are exploring what is possible but
>> > for the moment the answer is no. At present our focus is on providing the
>> > best open source solution we can for 4313, 43224, 43225, 4329 and future
>> > chips sets.
>>
>> Thanks for answer.
>>
>> Please, can you make totally sure person responsible for this gets it
>> totally right? I believe it's very important.
>>
>> The easiest step for you, which we still would appreciate is really
>> trivial one. It's *not* about writing any code, *not* about releasing
>> anything new. It's just about releasing in under friendly license.
>> This firmware is already available, we have access to it, we use it.
>> The problem is that distributions can not ship it.
>>
>> If you let me use simplification: all we need as first nice step is
>> Broadcom to say: "You can use it".
>
> That's not enough to allow Fedora to ship it. ?We'd need a clear license
> from Broadcom (ex the existing Intel or Marvell firmware licenses)
> before Fedora could feel comfortable about shipping it legally in all
> jurisdictions.
>
> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob;f=LICENCE.mwl8k;h=3224e1bbfba8ccd1d980f57eb88378f20bb2d146;hb=HEAD
> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob;f=LICENCE.libertas;h=1fd8766c26a170b50605455ae6f54b607baa12cf;hb=HEAD
>
> There's an existing Broadcom license in linux-firmware.git, and it *may*
> be OK, but it's really, really long and given that other major companies
> adopted the "shorter is better" approach, it's hard to believe that all
> the existing Broadcom license text is actually needed.

Few months later, is there any progress? Can we expect:

1) Easier licensing of currently provided firmware (see Fedore case)
2) Firmware for LP-PHY devices
?

-- 
Rafa?


From Larry.Finger at lwfinger.net  Fri Feb 18 17:21:29 2011
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Fri, 18 Feb 2011 16:21:29 -0600
Subject: Request for free-distributable Broadcom's (G|LP)-PHY firmware
In-Reply-To: <AANLkTikLbtV5dLu+Gu=8ibi=ERPiOykN9qBL4rPKS36g@mail.gmail.com>
References: <AANLkTik45KLdLf5UpjPtXTNgy4Df_BupyQ3SzRr6gZgC@mail.gmail.com>	<AANLkTin_JcEyT21dTS=Ew868HJvZQ2FVZBGXjCZn=8O_@mail.gmail.com>	<4CBF640C.4080405@broadcom.com>	<AANLkTinfwhjvfJU6C97SPJ8YKRqyJaCoQnAcC_uKLZa=@mail.gmail.com>	<1287674517.2383.7.camel@dcbw.foobar.com>
	<AANLkTikLbtV5dLu+Gu=8ibi=ERPiOykN9qBL4rPKS36g@mail.gmail.com>
Message-ID: <4D5EF0E9.4050908@lwfinger.net>

On 02/18/2011 03:24 PM, Rafa? Mi?ecki wrote:
> W dniu 21 pa?dziernika 2010 17:21 u?ytkownik Dan Williams
> <dcbw at redhat.com>  napisa?:
>> On Thu, 2010-10-21 at 00:11 +0200, Rafa? Mi?ecki wrote:
>>> W dniu 20 pa?dziernika 2010 23:50 u?ytkownik Henry Ptasinski
>>> <henryp at broadcom.com>  napisa?:
>>>> Sorry for the delay in responding.  We are exploring what is possible but
>>>> for the moment the answer is no. At present our focus is on providing the
>>>> best open source solution we can for 4313, 43224, 43225, 4329 and future
>>>> chips sets.
>>>
>>> Thanks for answer.
>>>
>>> Please, can you make totally sure person responsible for this gets it
>>> totally right? I believe it's very important.
>>>
>>> The easiest step for you, which we still would appreciate is really
>>> trivial one. It's *not* about writing any code, *not* about releasing
>>> anything new. It's just about releasing in under friendly license.
>>> This firmware is already available, we have access to it, we use it.
>>> The problem is that distributions can not ship it.
>>>
>>> If you let me use simplification: all we need as first nice step is
>>> Broadcom to say: "You can use it".
>>
>> That's not enough to allow Fedora to ship it.  We'd need a clear license
>> from Broadcom (ex the existing Intel or Marvell firmware licenses)
>> before Fedora could feel comfortable about shipping it legally in all
>> jurisdictions.
>>
>> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob;f=LICENCE.mwl8k;h=3224e1bbfba8ccd1d980f57eb88378f20bb2d146;hb=HEAD
>> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob;f=LICENCE.libertas;h=1fd8766c26a170b50605455ae6f54b607baa12cf;hb=HEAD
>>
>> There's an existing Broadcom license in linux-firmware.git, and it *may*
>> be OK, but it's really, really long and given that other major companies
>> adopted the "shorter is better" approach, it's hard to believe that all
>> the existing Broadcom license text is actually needed.
>
> Few months later, is there any progress? Can we expect:
>
> 1) Easier licensing of currently provided firmware (see Fedore case)
> 2) Firmware for LP-PHY devices
> ?

I think we can forget this whole business. It seems that Broadcom is content 
with their business model, even though knowledgeable Linux users are avoiding 
their products like the plague.

Larry


From zajec5 at gmail.com  Sun Feb 20 08:05:48 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Sun, 20 Feb 2011 14:05:48 +0100
Subject: bcm4322 success!
In-Reply-To: <201102201340.52880.christoph.thielecke@gmx.de>
References: <201101032121.10454.christoph.thielecke@gmx.de>
	<AANLkTikto8PkO8aD3x3i_E6b_GXKsx9XYJ0X+WjkrBaN@mail.gmail.com>
	<201102201340.52880.christoph.thielecke@gmx.de>
Message-ID: <AANLkTimRE9iAcoODyWmhcp0rOUAwEG_vy3Ozs7c3VM7N@mail.gmail.com>

W dniu 20 lutego 2011 13:40 u?ytkownik Christoph Thielecke
<christoph.thielecke at gmx.de> napisa?:
> Hello,
>
>> > I found your blog entry with the christmas gift:
>> > http://zajec.net/blog/view/2010-b43-and-nphy-rev-3-plus
>> > (Patch: http://marc.info/?l=linux-wireless&m=129296339527734&w=2)
>>
>> Your problems come from fact that you applied only final patch
>> enabling rev3+ support. That way you missed many important earlier
>> patches (for example the one enabling correct firmware loading).
>>
>> Please use sth like wireless-testing git tree to get all needed
>> patches. Using. compat-wireless may do the trick as well, however I
>> didn't try it.
> I can report success! I got it working at 2.6.38-rc5 by specifying options for
> b43 module.
> The specified options are:
> nohwcrypt=1 hwtkip=0 qos=0 pio=1 bad_frames_preempt=1
>
> I'm using it currently ~30 minutes and its working fine.

Thanks for your report! Do you need that all options at all? I think
hwtkip=0 is default one. Parameter qos should not matter. AFAIK pio is
needed for some BCM4321s only. I didn't check what bad_frames_preempt
does.


> wlan0 ? ? IEEE 802.11bg ?ESSID:"xxxxxxxxx"
> ? ? ? ? ?Mode:Managed ?Frequency:2.432 GHz ?Access Point: 00:14:BF:xx:xx:x
> ? ? ? ? ?Bit Rate=11 Mb/s ? Tx-Power=20 dBm
> ? ? ? ? ?Retry ?long limit:7 ? RTS thr:off ? Fragment thr:off
> ? ? ? ? ?Encryption key:off
> ? ? ? ? ?Power Management:off
> ? ? ? ? ?Link Quality=70/70 ?Signal level=0 dBm
> ? ? ? ? ?Rx invalid nwid:0 ?Rx invalid crypt:0 ?Rx invalid frag:0
> ? ? ? ? ?Tx excessive retries:4045 ?Invalid misc:1776 ? Missed beacon:0
>
> Its only 11Mbit (sure its a 54Mbit AP) but speed is constant ~ 500k/s.
>
> Btw: the driver from broadcom (wl) is NOT working but 4e3 does :-D

Hm, that's interesting. wl should work too.

As for speed, it's known issue. I still hope to get patches ready for
2.6.39 merge window.

-- 
Rafa?


From zajec5 at gmail.com  Sun Feb 20 08:41:42 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Sun, 20 Feb 2011 14:41:42 +0100
Subject: bcm4322 success (WPA2)!
In-Reply-To: <201102201431.45988.christoph.thielecke@gmx.de>
References: <201101032121.10454.christoph.thielecke@gmx.de>
	<201102201340.52880.christoph.thielecke@gmx.de>
	<AANLkTimRE9iAcoODyWmhcp0rOUAwEG_vy3Ozs7c3VM7N@mail.gmail.com>
	<201102201431.45988.christoph.thielecke@gmx.de>
Message-ID: <AANLkTik4xfzORZm03u+pMoezaV+HNUw-n7OqH-oZ_Dt1@mail.gmail.com>

Please, include b43-dev in to/cc.

W dniu 20 lutego 2011 14:31 u?ytkownik Christoph Thielecke
<christoph.thielecke at gmx.de> napisa?:
>> Thanks for your report! Do you need that all options at all?
> I think so. I'll try to remove some and tell which is needed for working. Here
> the results:
>
>> I think
>> hwtkip=0 is default one.
> Yes, works without that.
>
>> Parameter qos should not matter.
> qos=0 is nessary, qos=1 or without doesnt work.

What does happen when it doesn't work? Do you get scan results? Can
you associate? Get IP? Transmit?


>> AFAIK pio is
>> needed for some BCM4321s only.
> pio=1 is needed, pio=0 or without doesnt work.
>
>> I didn't check what bad_frames_preempt
>> does.
> bad_frames_preempt=1 is needed, bad_frames_preempt=0 or without doesnt work.
>
> So the needed options are:
> nohwcrypt=1 qos=0 pio=1 bad_frames_preempt=1

What does happen when it doesn't work? Do you get scan results? Can
you associate? Get IP? Transmit?


One request: please blacklist b43, do cold boot (turn off machine for
few seconds), then boot and load b43 with:
pio=1

I ask you for that, because it's possible that using DMA locks up your
card. In such a case further tests can give you false results.
Do you have scan results when using pio=1 after cold boot? Can you associate?

-- 
Rafa?


From clemens at helfmeier.de  Sun Feb 20 13:25:42 2011
From: clemens at helfmeier.de (Clemens Helfmeier)
Date: Sun, 20 Feb 2011 19:25:42 +0100
Subject: bcm4322 success (WPA2)!
In-Reply-To: <AANLkTik4xfzORZm03u+pMoezaV+HNUw-n7OqH-oZ_Dt1@mail.gmail.com>
References: <201101032121.10454.christoph.thielecke@gmx.de>
	<201102201340.52880.christoph.thielecke@gmx.de>
	<AANLkTimRE9iAcoODyWmhcp0rOUAwEG_vy3Ozs7c3VM7N@mail.gmail.com>
	<201102201431.45988.christoph.thielecke@gmx.de>
	<AANLkTik4xfzORZm03u+pMoezaV+HNUw-n7OqH-oZ_Dt1@mail.gmail.com>
Message-ID: <20110220182541.GP6696@helfmeier.de>

Hello Developers,

I have just tried the current wireless-testing git tree with my bcm4322 device:

# lshw
0c:00.0 Network controller [0280]: Broadcom Corporation BCM4322 802.11a/b/g/n
    Wireless LAN Controller [14e4:432b] (rev 01)

# dmesg shows:
[   11.358762] b43-phy0: Broadcom 4322 WLAN found (core revision 16)
[   11.400231] b43-phy0 debug: Found PHY: Analog 8, Type 4, Revision 4 
[   11.400257] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2056, Revision 3

I had to apply this patch to b43-fwcutter in order to extract the firmware: 
http://lists.infradead.org/pipermail/b43-dev/2010-July/000225.html

Using WPA2, the connection is very stable, no connection break downs so far.

My dmesg log shows quite a lot of error messages (approx every 7 seconds in 
idle and more often when traffic is high):
[ 4015.044435] b43-phy0 ERROR: PHY transmission error
[ 4021.910720] b43-phy0 ERROR: PHY transmission error
[ 4028.866892] b43-phy0 ERROR: PHY transmission error

Thanks for your efforts to get my hardware working!

Best regards,
 Clemens

On Sun, Feb 20, 2011 at 02:41:42PM +0100, Rafa? Mi?ecki wrote:
> Please, include b43-dev in to/cc.
> 
> W dniu 20 lutego 2011 14:31 u?ytkownik Christoph Thielecke
> <christoph.thielecke at gmx.de> napisa?:
>>> Thanks for your report! Do you need that all options at all?
>> I think so. I'll try to remove some and tell which is needed for working. 
>> Here the results:
>> 
>>> I think
>>> hwtkip=0 is default one.
>> Yes, works without that.
>> 
>>> Parameter qos should not matter.
>> qos=0 is nessary, qos=1 or without doesnt work.
> 
> What does happen when it doesn't work? Do you get scan results? Can you 
> associate? Get IP? Transmit?
> 
> 
>>> AFAIK pio is
>>> needed for some BCM4321s only.
>> pio=1 is needed, pio=0 or without doesnt work.
>> 
>>> I didn't check what bad_frames_preempt
>>> does.
>> bad_frames_preempt=1 is needed, bad_frames_preempt=0 or without doesnt work.
>> 
>> So the needed options are:
>> nohwcrypt=1 qos=0 pio=1 bad_frames_preempt=1
> 
> What does happen when it doesn't work? Do you get scan results? Can you 
> associate? Get IP? Transmit?
> 
> 
> One request: please blacklist b43, do cold boot (turn off machine for few 
> seconds), then boot and load b43 with:
> pio=1
> 
> I ask you for that, because it's possible that using DMA locks up your card. 
> In such a case further tests can give you false results.
> Do you have scan results when using pio=1 after cold boot? Can you associate?
> 
> --
> Rafa?
> 
> _______________________________________________
> b43-dev mailing list
> b43-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/b43-dev

 Clemens Helfmeier


From zajec5 at gmail.com  Sun Feb 20 14:27:51 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Sun, 20 Feb 2011 20:27:51 +0100
Subject: bcm4322 success (WPA2)!
In-Reply-To: <20110220182541.GP6696@helfmeier.de>
References: <201101032121.10454.christoph.thielecke@gmx.de>
	<201102201340.52880.christoph.thielecke@gmx.de>
	<AANLkTimRE9iAcoODyWmhcp0rOUAwEG_vy3Ozs7c3VM7N@mail.gmail.com>
	<201102201431.45988.christoph.thielecke@gmx.de>
	<AANLkTik4xfzORZm03u+pMoezaV+HNUw-n7OqH-oZ_Dt1@mail.gmail.com>
	<20110220182541.GP6696@helfmeier.de>
Message-ID: <AANLkTi=p50uBUTLQO6Jx0N1ODbpwSHxk3jx7aN4yPP-R@mail.gmail.com>

2011/2/20 Clemens Helfmeier <clemens at helfmeier.de>:
> I had to apply this patch to b43-fwcutter in order to extract the firmware:
> http://lists.infradead.org/pipermail/b43-dev/2010-July/000225.html

Yeah, there was some discussion about getting newer firmware. It's
unfortunately available only in huge firmware and Broadcom doesn't
give a sh* about providing open source community freely available
firmware. That's all about their openess and positive talks brcm80211
related.

For now you have to download huge firmware (and hacking extractor) or
try linking ucode16_mimo to ucode16.


> Using WPA2, the connection is very stable, no connection break downs so far.

We have some positive reports and not-so-much (coming for example from
Larry). Good to head there is one more person having this working.


> My dmesg log shows quite a lot of error messages (approx every 7 seconds in
> idle and more often when traffic is high):
> [ 4015.044435] b43-phy0 ERROR: PHY transmission error
> [ 4021.910720] b43-phy0 ERROR: PHY transmission error
> [ 4028.866892] b43-phy0 ERROR: PHY transmission error
>
> Thanks for your efforts to get my hardware working!

Just for sure: can you try forcing rate to 1M, 2M or 11M? Does it
noticeably lowers amount of reported PHY errors? The command you need
to use is like:
iwconfig wlan0 rate 1M
iwconfig wlan0 rate 2M
iwconfig wlan0 rate 11M

-- 
Rafa?


From Larry.Finger at lwfinger.net  Sun Feb 20 14:30:36 2011
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Sun, 20 Feb 2011 13:30:36 -0600
Subject: bcm4322 success (WPA2)!
In-Reply-To: <20110220182541.GP6696@helfmeier.de>
References: <201101032121.10454.christoph.thielecke@gmx.de>	<201102201340.52880.christoph.thielecke@gmx.de>	<AANLkTimRE9iAcoODyWmhcp0rOUAwEG_vy3Ozs7c3VM7N@mail.gmail.com>	<201102201431.45988.christoph.thielecke@gmx.de>	<AANLkTik4xfzORZm03u+pMoezaV+HNUw-n7OqH-oZ_Dt1@mail.gmail.com>
	<20110220182541.GP6696@helfmeier.de>
Message-ID: <4D616BDC.6080504@lwfinger.net>

On 02/20/2011 12:25 PM, Clemens Helfmeier wrote:
> Hello Developers,
>
> I have just tried the current wireless-testing git tree with my bcm4322 device:
>
> # lshw
> 0c:00.0 Network controller [0280]: Broadcom Corporation BCM4322 802.11a/b/g/n
>      Wireless LAN Controller [14e4:432b] (rev 01)
>
> # dmesg shows:
> [   11.358762] b43-phy0: Broadcom 4322 WLAN found (core revision 16)
> [   11.400231] b43-phy0 debug: Found PHY: Analog 8, Type 4, Revision 4
> [   11.400257] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2056, Revision 3
>
> I had to apply this patch to b43-fwcutter in order to extract the firmware:
> http://lists.infradead.org/pipermail/b43-dev/2010-July/000225.html
>
> Using WPA2, the connection is very stable, no connection break downs so far.
>
> My dmesg log shows quite a lot of error messages (approx every 7 seconds in
> idle and more often when traffic is high):
> [ 4015.044435] b43-phy0 ERROR: PHY transmission error
> [ 4021.910720] b43-phy0 ERROR: PHY transmission error
> [ 4028.866892] b43-phy0 ERROR: PHY transmission error
>
> Thanks for your efforts to get my hardware working!

The attached patch should fix the PHY transmission errors, which happens 
whenever the rate control code tries to set an OFDM rate. With the patch, those 
rates will not work, but no errors will be printed.

You can also lock the rate at 11M (iwconfig wlan0 rate 11M) to get rid of those 
errors.

Larry

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: b43_tx_set_control_word1
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110220/581de113/attachment.ksh>

From teg at jklm.no  Sun Feb 20 19:05:47 2011
From: teg at jklm.no (Tom Gundersen)
Date: Mon, 21 Feb 2011 01:05:47 +0100
Subject: bcm4322 success (WPA2)!
In-Reply-To: <AANLkTi=p50uBUTLQO6Jx0N1ODbpwSHxk3jx7aN4yPP-R@mail.gmail.com>
References: <201101032121.10454.christoph.thielecke@gmx.de>
	<201102201340.52880.christoph.thielecke@gmx.de>
	<AANLkTimRE9iAcoODyWmhcp0rOUAwEG_vy3Ozs7c3VM7N@mail.gmail.com>
	<201102201431.45988.christoph.thielecke@gmx.de>
	<AANLkTik4xfzORZm03u+pMoezaV+HNUw-n7OqH-oZ_Dt1@mail.gmail.com>
	<20110220182541.GP6696@helfmeier.de>
	<AANLkTi=p50uBUTLQO6Jx0N1ODbpwSHxk3jx7aN4yPP-R@mail.gmail.com>
Message-ID: <AANLkTinarPPuNDXtxC=AoakSWn63mpqjcGJ3EM=magBg@mail.gmail.com>

Hi Rafa?,

I also have a bcm4322 chip, which works with WPA2 using 2.6.38-rc5.

2011/2/20 Rafa? Mi?ecki <zajec5 at gmail.com>:
> For now you have to download huge firmware (and hacking extractor) or
> try linking ucode16_mimo to ucode16.

This is the only thing I had to do to make it work.

> 2011/2/20 Clemens Helfmeier <clemens at helfmeier.de>:
>> My dmesg log shows quite a lot of error messages (approx every 7 seconds in
>> idle and more often when traffic is high):
>> [ 4015.044435] b43-phy0 ERROR: PHY transmission error
>> [ 4021.910720] b43-phy0 ERROR: PHY transmission error
>> [ 4028.866892] b43-phy0 ERROR: PHY transmission error

I'm seeing about the same here.

Furthermore, I get about 5% packet loss when pinging my wireless
router (with no other traffic).

> Just for sure: can you try forcing rate to 1M, 2M or 11M? Does it
> noticeably lowers amount of reported PHY errors? The command you need
> to use is like:
> iwconfig wlan0 rate 1M
> iwconfig wlan0 rate 2M
> iwconfig wlan0 rate 11M

iwconfig says that my rate is 11 Mb/s, but since I expected it to be
54, I figured this might be wrong, so I tried
% iwconfig wlan0 rate 11M

This appears to solve the problem completely! I have not seen any more
errors and my packet loss is 0%. (The download speed is still
suboptimal, but I read that you already have some patches for that, so
I'll just wait for when they are posted.)

Thanks for making this work! (It is infinitely better than the wl
driver...). If ever you need some testing of new patches related to my
card, let me know.

Cheers,

Tom


FYI:

% lspci -vvv -d 43
lspci -vvv -d :432b
0c:00.0 Network controller: Broadcom Corporation BCM4322 802.11a/b/g/n
Wireless LAN Controller (rev 01)
        Subsystem: Dell Wireless 1510 Wireless-N WLAN Mini-Card
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at f69fc000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: b43-pci-bridge
        Kernel modules: ssb

% dmesg | grep b43 | grep -v error
[    4.634710] b43-pci-bridge 0000:0c:00.0: PCI INT A -> GSI 17
(level, low) -> IRQ 17
[    4.634726] b43-pci-bridge 0000:0c:00.0: setting latency timer to 64
[    5.081082] b43-phy0: Broadcom 4322 WLAN found (core revision 16)
[    5.120182] b43-phy0 debug: Found PHY: Analog 8, Type 4, Revision 4
[    5.120211] b43-phy0 debug: Found Radio: Manuf 0x17F, Version
0x2056, Revision 3
[    5.153525] Registered led device: b43-phy0::tx
[    5.153598] Registered led device: b43-phy0::rx
[    5.153660] Registered led device: b43-phy0::radio
[    7.170069] b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
[    7.300260] b43-phy0 debug: Chip initialized
[    7.300426] b43-phy0 debug: 64-bit DMA initialized
[    7.300514] b43-phy0 debug: QoS enabled
[    7.317592] b43-phy0 debug: Wireless interface started
[    7.317611] b43-phy0 debug: Adding Interface type 2
[   13.439529] b43-phy0 debug: Using hardware based encryption for
keyidx: 0, mac: 5c:33:8e:ea:24:f3
[   13.439619] b43-phy0 debug: Using hardware based encryption for
keyidx: 1, mac: ff:ff:ff:ff:ff:ff


From clemens at helfmeier.de  Mon Feb 21 02:56:01 2011
From: clemens at helfmeier.de (Clemens Helfmeier)
Date: Mon, 21 Feb 2011 08:56:01 +0100
Subject: bcm4322 success (WPA2)!
In-Reply-To: <4D616BDC.6080504@lwfinger.net>
References: <201101032121.10454.christoph.thielecke@gmx.de>
	<201102201340.52880.christoph.thielecke@gmx.de>
	<AANLkTimRE9iAcoODyWmhcp0rOUAwEG_vy3Ozs7c3VM7N@mail.gmail.com>
	<201102201431.45988.christoph.thielecke@gmx.de>
	<AANLkTik4xfzORZm03u+pMoezaV+HNUw-n7OqH-oZ_Dt1@mail.gmail.com>
	<20110220182541.GP6696@helfmeier.de>
	<4D616BDC.6080504@lwfinger.net>
Message-ID: <20110221075600.GQ6696@helfmeier.de>

Hello Larry,

On Sun, Feb 20, 2011 at 01:30:36PM -0600, Larry Finger wrote:
> On 02/20/2011 12:25 PM, Clemens Helfmeier wrote:
>> Hello Developers,
>> 
>> I have just tried the current wireless-testing git tree with my bcm4322 
>> device:
>> 
>> # lshw
>> 0c:00.0 Network controller [0280]: Broadcom Corporation BCM4322 
>> 802.11a/b/g/n
>>     Wireless LAN Controller [14e4:432b] (rev 01)
>> 
>> # dmesg shows:
>> [   11.358762] b43-phy0: Broadcom 4322 WLAN found (core revision 16) [   
>> 11.400231] b43-phy0 debug: Found PHY: Analog 8, Type 4, Revision 4 [   
>> 11.400257] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2056, 
>> Revision 3
>> 
>> I had to apply this patch to b43-fwcutter in order to extract the firmware: 
>> http://lists.infradead.org/pipermail/b43-dev/2010-July/000225.html
>> 
>> Using WPA2, the connection is very stable, no connection break downs so far.
>> 
>> My dmesg log shows quite a lot of error messages (approx every 7 seconds in 
>> idle and more often when traffic is high):
>> [ 4015.044435] b43-phy0 ERROR: PHY transmission error
>> [ 4021.910720] b43-phy0 ERROR: PHY transmission error
>> [ 4028.866892] b43-phy0 ERROR: PHY transmission error
>> 
>> Thanks for your efforts to get my hardware working!
> 
> The attached patch should fix the PHY transmission errors, which happens 
> whenever the rate control code tries to set an OFDM rate. With the patch, 
> those rates will not work, but no errors will be printed.
> 
> You can also lock the rate at 11M (iwconfig wlan0 rate 11M) to get rid of 
> those errors.

Locking the rate at 11M makes the driver not output any more error messages 
here ,too.
Thanks for your work!

Best regards,
 Clemens



From netrolller.3d at gmail.com  Mon Feb 21 09:23:00 2011
From: netrolller.3d at gmail.com (=?ISO-8859-1?Q?G=E1bor_Stefanik?=)
Date: Mon, 21 Feb 2011 15:23:00 +0100
Subject: Request for free-distributable Broadcom's (G|LP)-PHY firmware
In-Reply-To: <20110221095957.GA4568@redhat.com>
References: <AANLkTik45KLdLf5UpjPtXTNgy4Df_BupyQ3SzRr6gZgC@mail.gmail.com>
	<AANLkTin_JcEyT21dTS=Ew868HJvZQ2FVZBGXjCZn=8O_@mail.gmail.com>
	<4CBF640C.4080405@broadcom.com>
	<AANLkTinfwhjvfJU6C97SPJ8YKRqyJaCoQnAcC_uKLZa=@mail.gmail.com>
	<1287674517.2383.7.camel@dcbw.foobar.com>
	<AANLkTikLbtV5dLu+Gu=8ibi=ERPiOykN9qBL4rPKS36g@mail.gmail.com>
	<4D5EF0E9.4050908@lwfinger.net> <20110221095957.GA4568@redhat.com>
Message-ID: <AANLkTinYnzX_xOCCk44khXrEW_p-6uS4PP2JDTfddPk9@mail.gmail.com>

On Mon, Feb 21, 2011 at 10:59 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
> On Fri, Feb 18, 2011 at 04:21:29PM -0600, Larry Finger wrote:
>> On 02/18/2011 03:24 PM, Rafa? Mi?ecki wrote:
>> >Few months later, is there any progress? Can we expect:
>> >
>> >1) Easier licensing of currently provided firmware (see Fedore case)
>> >2) Firmware for LP-PHY devices
>> >?
>>
>> I think we can forget this whole business. It seems that Broadcom is
>> content with their business model, even though knowledgeable Linux
>> users are avoiding their products like the plague.
>
> Broadcom will not release old firmware with redistributable license,
> because of legal concerns, which are ridiculous for everyone except
> them.
>
> http://lists.fedoraproject.org/pipermail/devel/2010-September/142893.html
>
> That sucks.
>

This looks like the same argument Intel is using to justify long
delays before releasing new firmware - it needs to pass regulatory
testing to ensure that regulatory restrictions in released FW cannot
be circumvented. Both seem rather odd in light of Atheros's
open-source firmware projects and general "conformant-by-default, but
no "DRM" to prevent regulatory infringement" policy - though I seem to
remember that Atheros acquired SDR certification, while Broadcom and
Intel both went for regular "part 11" certification only. AFAIK the
rules for SDRs are much more lax than those for part-11-only devices.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)


From zajec5 at gmail.com  Mon Feb 21 09:49:05 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Mon, 21 Feb 2011 15:49:05 +0100
Subject: Request for free-distributable Broadcom's (G|LP)-PHY firmware
In-Reply-To: <AANLkTinYnzX_xOCCk44khXrEW_p-6uS4PP2JDTfddPk9@mail.gmail.com>
References: <AANLkTik45KLdLf5UpjPtXTNgy4Df_BupyQ3SzRr6gZgC@mail.gmail.com>
	<AANLkTin_JcEyT21dTS=Ew868HJvZQ2FVZBGXjCZn=8O_@mail.gmail.com>
	<4CBF640C.4080405@broadcom.com>
	<AANLkTinfwhjvfJU6C97SPJ8YKRqyJaCoQnAcC_uKLZa=@mail.gmail.com>
	<1287674517.2383.7.camel@dcbw.foobar.com>
	<AANLkTikLbtV5dLu+Gu=8ibi=ERPiOykN9qBL4rPKS36g@mail.gmail.com>
	<4D5EF0E9.4050908@lwfinger.net> <20110221095957.GA4568@redhat.com>
	<AANLkTinYnzX_xOCCk44khXrEW_p-6uS4PP2JDTfddPk9@mail.gmail.com>
Message-ID: <AANLkTinQm7p7yaB14VJtBAZXdQAf3EmoqK-dH2Ofdk=8@mail.gmail.com>

2011/2/21 G?bor Stefanik <netrolller.3d at gmail.com>:
> On Mon, Feb 21, 2011 at 10:59 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
>> On Fri, Feb 18, 2011 at 04:21:29PM -0600, Larry Finger wrote:
>>> On 02/18/2011 03:24 PM, Rafa? Mi?ecki wrote:
>>> >Few months later, is there any progress? Can we expect:
>>> >
>>> >1) Easier licensing of currently provided firmware (see Fedore case)
>>> >2) Firmware for LP-PHY devices
>>> >?
>>>
>>> I think we can forget this whole business. It seems that Broadcom is
>>> content with their business model, even though knowledgeable Linux
>>> users are avoiding their products like the plague.
>>
>> Broadcom will not release old firmware with redistributable license,
>> because of legal concerns, which are ridiculous for everyone except
>> them.
>>
>> http://lists.fedoraproject.org/pipermail/devel/2010-September/142893.html
>>
>> That sucks.
>>
>
> This looks like the same argument Intel is using to justify long
> delays before releasing new firmware - it needs to pass regulatory
> testing to ensure that regulatory restrictions in released FW cannot
> be circumvented. Both seem rather odd in light of Atheros's
> open-source firmware projects and general "conformant-by-default, but
> no "DRM" to prevent regulatory infringement" policy - though I seem to
> remember that Atheros acquired SDR certification, while Broadcom and
> Intel both went for regular "part 11" certification only. AFAIK the
> rules for SDRs are much more lax than those for part-11-only devices.

But Broadcom's firmware was already released, it's commonly used. Plus
they already published some N-PHY AI firmware in linux-firmware tree.
The whole situation just does not make any sense.

-- 
Rafa?


From Larry.Finger at lwfinger.net  Mon Feb 21 11:09:27 2011
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Mon, 21 Feb 2011 10:09:27 -0600
Subject: Request for free-distributable Broadcom's (G|LP)-PHY firmware
In-Reply-To: <20110221095957.GA4568@redhat.com>
References: <AANLkTik45KLdLf5UpjPtXTNgy4Df_BupyQ3SzRr6gZgC@mail.gmail.com>
	<AANLkTin_JcEyT21dTS=Ew868HJvZQ2FVZBGXjCZn=8O_@mail.gmail.com>
	<4CBF640C.4080405@broadcom.com>
	<AANLkTinfwhjvfJU6C97SPJ8YKRqyJaCoQnAcC_uKLZa=@mail.gmail.com>
	<1287674517.2383.7.camel@dcbw.foobar.com>
	<AANLkTikLbtV5dLu+Gu=8ibi=ERPiOykN9qBL4rPKS36g@mail.gmail.com>
	<4D5EF0E9.4050908@lwfinger.net> <20110221095957.GA4568@redhat.com>
Message-ID: <4D628E37.7040503@lwfinger.net>

On 02/21/2011 03:59 AM, Stanislaw Gruszka wrote:
> On Fri, Feb 18, 2011 at 04:21:29PM -0600, Larry Finger wrote:
>> On 02/18/2011 03:24 PM, Rafa? Mi?ecki wrote:
>>> Few months later, is there any progress? Can we expect:
>>>
>>> 1) Easier licensing of currently provided firmware (see Fedore case)
>>> 2) Firmware for LP-PHY devices
>>> ?
>>
>> I think we can forget this whole business. It seems that Broadcom is
>> content with their business model, even though knowledgeable Linux
>> users are avoiding their products like the plague.
>
> Broadcom will not release old firmware with redistributable license,
> because of legal concerns, which are ridiculous for everyone except
> them.
>
> http://lists.fedoraproject.org/pipermail/devel/2010-September/142893.html

Did I tell you that I hate lawyers?

Larry


From zajec5 at gmail.com  Mon Feb 21 13:38:58 2011
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Mon, 21 Feb 2011 19:38:58 +0100
Subject: [PATCH] b43: N-PHY: fix 0x2055 radio workaround condition
Message-ID: <1298313538-3904-1-git-send-email-zajec5@gmail.com>

Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>
---
 drivers/net/wireless/b43/phy_n.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index 2186afc..9f5a3c9 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -430,9 +430,9 @@ static void b43_radio_init2055_post(struct b43_wldev *dev)
 	bool workaround = false;
 
 	if (sprom->revision < 4)
-		workaround = (binfo->vendor != PCI_VENDOR_ID_BROADCOM ||
-				binfo->type != 0x46D ||
-				binfo->rev < 0x41);
+		workaround = (binfo->vendor != PCI_VENDOR_ID_BROADCOM &&
+				binfo->type == 0x46D &&
+				binfo->rev >= 0x41);
 	else
 		workaround =
 			!(sprom->boardflags2_lo & B43_BFL2_RXBB_INT_REG_DIS);
-- 
1.7.1



From zajec5 at gmail.com  Mon Feb 21 13:45:34 2011
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Mon, 21 Feb 2011 19:45:34 +0100
Subject: [PATCH 1/2] b43: N-PHY: rev1: enable some gain ctl workarounds
Message-ID: <1298313935-4094-1-git-send-email-zajec5@gmail.com>

Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>
---
 drivers/net/wireless/b43/phy_n.c |   18 +++++++++---------
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index ab81ed8..cc19e3f 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -1281,17 +1281,17 @@ static void b43_nphy_gain_ctrl_workarounds(struct b43_wldev *dev)
 						B43_NPHY_TABLE_DATALO, tmp);
 				}
 			}
+		}
 
-			b43_nphy_set_rf_sequence(dev, 5,
-					rfseq_events, rfseq_delays, 3);
-			b43_phy_maskset(dev, B43_NPHY_OVER_DGAIN1,
-				~B43_NPHY_OVER_DGAIN_CCKDGECV & 0xFFFF,
-				0x5A << B43_NPHY_OVER_DGAIN_CCKDGECV_SHIFT);
+		b43_nphy_set_rf_sequence(dev, 5,
+				rfseq_events, rfseq_delays, 3);
+		b43_phy_maskset(dev, B43_NPHY_OVER_DGAIN1,
+			~B43_NPHY_OVER_DGAIN_CCKDGECV & 0xFFFF,
+			0x5A << B43_NPHY_OVER_DGAIN_CCKDGECV_SHIFT);
 
-			if (b43_current_band(dev->wl) == IEEE80211_BAND_2GHZ)
-				b43_phy_maskset(dev, B43_PHY_N(0xC5D),
-						0xFF80, 4);
-		}
+		if (b43_current_band(dev->wl) == IEEE80211_BAND_2GHZ)
+			b43_phy_maskset(dev, B43_PHY_N(0xC5D),
+					0xFF80, 4);
 	}
 }
 
-- 
1.7.1



From zajec5 at gmail.com  Mon Feb 21 13:45:35 2011
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Mon, 21 Feb 2011 19:45:35 +0100
Subject: [PATCH 2/2] b43: N-PHY: rev1: restore PHY state after RSSI operations
In-Reply-To: <1298313935-4094-1-git-send-email-zajec5@gmail.com>
References: <1298313935-4094-1-git-send-email-zajec5@gmail.com>
Message-ID: <1298313935-4094-2-git-send-email-zajec5@gmail.com>

Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>
---
 drivers/net/wireless/b43/phy_n.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index cc19e3f..2186afc 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -2128,7 +2128,7 @@ static int b43_nphy_poll_rssi(struct b43_wldev *dev, u8 type, s32 *buf,
 		save_regs_phy[5] = b43_phy_read(dev, B43_NPHY_AFECTL_OVER);
 		save_regs_phy[6] = b43_phy_read(dev, B43_NPHY_TXF_40CO_B1S0);
 		save_regs_phy[7] = b43_phy_read(dev, B43_NPHY_TXF_40CO_B32S1);
-	} else if (dev->phy.rev == 2) {
+	} else {
 		save_regs_phy[0] = b43_phy_read(dev, B43_NPHY_AFECTL_C1);
 		save_regs_phy[1] = b43_phy_read(dev, B43_NPHY_AFECTL_C2);
 		save_regs_phy[2] = b43_phy_read(dev, B43_NPHY_AFECTL_OVER);
@@ -2179,7 +2179,7 @@ static int b43_nphy_poll_rssi(struct b43_wldev *dev, u8 type, s32 *buf,
 		b43_phy_write(dev, B43_NPHY_AFECTL_OVER, save_regs_phy[5]);
 		b43_phy_write(dev, B43_NPHY_TXF_40CO_B1S0, save_regs_phy[6]);
 		b43_phy_write(dev, B43_NPHY_TXF_40CO_B32S1, save_regs_phy[7]);
-	} else if (dev->phy.rev == 2) {
+	} else {
 		b43_phy_write(dev, B43_NPHY_AFECTL_C1, save_regs_phy[0]);
 		b43_phy_write(dev, B43_NPHY_AFECTL_C2, save_regs_phy[1]);
 		b43_phy_write(dev, B43_NPHY_AFECTL_OVER, save_regs_phy[2]);
-- 
1.7.1



From zajec5 at gmail.com  Mon Feb 21 13:55:12 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Mon, 21 Feb 2011 19:55:12 +0100
Subject: bcm4322 success (WPA2)!
In-Reply-To: <201102201930.43815.christoph.thielecke@gmx.de>
References: <201101032121.10454.christoph.thielecke@gmx.de>
	<201102201431.45988.christoph.thielecke@gmx.de>
	<AANLkTik4xfzORZm03u+pMoezaV+HNUw-n7OqH-oZ_Dt1@mail.gmail.com>
	<201102201930.43815.christoph.thielecke@gmx.de>
Message-ID: <AANLkTinrL5TxgFdwqHnRs4j6OuwX62y6O_hVTh_9AXgV@mail.gmail.com>

W dniu 20 lutego 2011 19:30 u?ytkownik Christoph Thielecke
<christoph.thielecke at gmx.de> napisa?:
> I played a little bit with the options and the only stable working case seems
> nohwcrypt=1 hwtkip=0 qos=0 pio=1 bad_frames_preempt=1
>
> I dont know why the other cases sometimes work.

Thanks for your tests, however I can not offer you anything right now.
I hope it will get more stable when we get TX patch, some general PHY
rev 3+ improvements and DMA fix. Will try to remember to ping you then
:)

-- 
Rafa?


From mcgrof at gmail.com  Mon Feb 21 14:15:07 2011
From: mcgrof at gmail.com (Luis R. Rodriguez)
Date: Mon, 21 Feb 2011 11:15:07 -0800
Subject: Request for free-distributable Broadcom's (G|LP)-PHY firmware
In-Reply-To: <AANLkTinYnzX_xOCCk44khXrEW_p-6uS4PP2JDTfddPk9@mail.gmail.com>
References: <AANLkTik45KLdLf5UpjPtXTNgy4Df_BupyQ3SzRr6gZgC@mail.gmail.com>
	<AANLkTin_JcEyT21dTS=Ew868HJvZQ2FVZBGXjCZn=8O_@mail.gmail.com>
	<4CBF640C.4080405@broadcom.com>
	<AANLkTinfwhjvfJU6C97SPJ8YKRqyJaCoQnAcC_uKLZa=@mail.gmail.com>
	<1287674517.2383.7.camel@dcbw.foobar.com>
	<AANLkTikLbtV5dLu+Gu=8ibi=ERPiOykN9qBL4rPKS36g@mail.gmail.com>
	<4D5EF0E9.4050908@lwfinger.net> <20110221095957.GA4568@redhat.com>
	<AANLkTinYnzX_xOCCk44khXrEW_p-6uS4PP2JDTfddPk9@mail.gmail.com>
Message-ID: <AANLkTik-bLy7VFmoyca-Qve_mnM7XfSSR-=ZYUPJkobH@mail.gmail.com>

On Mon, Feb 21, 2011 at 6:23 AM, G?bor Stefanik <netrolller.3d at gmail.com> wrote:
> On Mon, Feb 21, 2011 at 10:59 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
>> On Fri, Feb 18, 2011 at 04:21:29PM -0600, Larry Finger wrote:
>>> On 02/18/2011 03:24 PM, Rafa? Mi?ecki wrote:
>>> >Few months later, is there any progress? Can we expect:
>>> >
>>> >1) Easier licensing of currently provided firmware (see Fedore case)
>>> >2) Firmware for LP-PHY devices
>>> >?
>>>
>>> I think we can forget this whole business. It seems that Broadcom is
>>> content with their business model, even though knowledgeable Linux
>>> users are avoiding their products like the plague.
>>
>> Broadcom will not release old firmware with redistributable license,
>> because of legal concerns, which are ridiculous for everyone except
>> them.
>>
>> http://lists.fedoraproject.org/pipermail/devel/2010-September/142893.html
>>
>> That sucks.
>>
>
> This looks like the same argument Intel is using to justify long
> delays before releasing new firmware - it needs to pass regulatory
> testing to ensure that regulatory restrictions in released FW cannot
> be circumvented. Both seem rather odd in light of Atheros's
> open-source firmware projects and general "conformant-by-default, but
> no "DRM" to prevent regulatory infringement" policy - though I seem to
> remember that Atheros acquired SDR certification, while Broadcom and
> Intel both went for regular "part 11" certification only. AFAIK the
> rules for SDRs are much more lax than those for part-11-only devices.

Huh ? No, there have been no 802.11 SDR certificiations by Atheros or
any modern vendor. We're all on the same boat.

  Luis


From zajec5 at gmail.com  Fri Feb 25 06:34:11 2011
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Fri, 25 Feb 2011 12:34:11 +0100
Subject: [PATCH] b43: fill PHY ctl word1 in TX header for N-PHY
Message-ID: <1298633651-5641-1-git-send-email-zajec5@gmail.com>

This patch fixes tramissing on OFDM rates for PHYs 1 and 2. There is
still something wrong with PHYs 3+. Tests has shown decreasing of
performance on CCK rates by 1-2%, we have to live with that.
Additionaly this noticeably reduces amount of PHY errors. They were
mostly produced by auto-switching to higher rate for better
performanced, which resulted in no transmit at all and PHY errors.

Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>
---
 drivers/net/wireless/b43/xmit.c |   73 +++++++++++++++++++++++++++++++++++++++
 drivers/net/wireless/b43/xmit.h |    6 +++
 2 files changed, 79 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/b43/xmit.c b/drivers/net/wireless/b43/xmit.c
index e6b0528..9866686 100644
--- a/drivers/net/wireless/b43/xmit.c
+++ b/drivers/net/wireless/b43/xmit.c
@@ -32,6 +32,36 @@
 #include "dma.h"
 #include "pio.h"
 
+static const struct b43_tx_legacy_rate_phy_ctl_entry b43_tx_legacy_rate_phy_ctl[] = {
+	{ B43_CCK_RATE_1MB,	0x0,			0x0 },
+	{ B43_CCK_RATE_2MB,	0x0,			0x1 },
+	{ B43_CCK_RATE_5MB,	0x0,			0x2 },
+	{ B43_CCK_RATE_11MB,	0x0,			0x3 },
+	{ B43_OFDM_RATE_6MB,	B43_TXH_PHY1_CRATE_1_2,	B43_TXH_PHY1_MODUL_BPSK },
+	{ B43_OFDM_RATE_9MB,	B43_TXH_PHY1_CRATE_3_4,	B43_TXH_PHY1_MODUL_BPSK },
+	{ B43_OFDM_RATE_12MB,	B43_TXH_PHY1_CRATE_1_2,	B43_TXH_PHY1_MODUL_QPSK },
+	{ B43_OFDM_RATE_18MB,	B43_TXH_PHY1_CRATE_3_4,	B43_TXH_PHY1_MODUL_QPSK },
+	{ B43_OFDM_RATE_24MB,	B43_TXH_PHY1_CRATE_1_2,	B43_TXH_PHY1_MODUL_QAM16 },
+	{ B43_OFDM_RATE_36MB,	B43_TXH_PHY1_CRATE_3_4,	B43_TXH_PHY1_MODUL_QAM16 },
+	{ B43_OFDM_RATE_48MB,	B43_TXH_PHY1_CRATE_2_3,	B43_TXH_PHY1_MODUL_QAM64 },
+	{ B43_OFDM_RATE_54MB,	B43_TXH_PHY1_CRATE_3_4,	B43_TXH_PHY1_MODUL_QAM64 },
+};
+
+static const struct b43_tx_legacy_rate_phy_ctl_entry *
+b43_tx_legacy_rate_phy_ctl_ent(u8 bitrate)
+{
+	const struct b43_tx_legacy_rate_phy_ctl_entry *e;
+	unsigned int i;
+
+	for (i = 0; i < ARRAY_SIZE(b43_tx_legacy_rate_phy_ctl); i++) {
+		e = &(b43_tx_legacy_rate_phy_ctl[i]);
+		if (e->bitrate == bitrate)
+			return e;
+	}
+
+	B43_WARN_ON(1);
+	return NULL;
+}
 
 /* Extract the bitrate index out of a CCK PLCP header. */
 static int b43_plcp_get_bitrate_idx_cck(struct b43_plcp_hdr6 *plcp)
@@ -145,6 +175,34 @@ void b43_generate_plcp_hdr(struct b43_plcp_hdr4 *plcp,
 	}
 }
 
+static u16 b43_generate_tx_phy_ctl1(struct b43_wldev *dev, u8 bitrate)
+{
+	const struct b43_phy *phy = &dev->phy;
+	const struct b43_tx_legacy_rate_phy_ctl_entry *e;
+	u16 control = 0;
+	u16 bw;
+
+	if (phy->type == B43_PHYTYPE_LP)
+		bw = B43_TXH_PHY1_BW_20;
+	else /* FIXME */
+		bw = B43_TXH_PHY1_BW_20;
+
+	if (0) { /* FIXME: MIMO */
+	} else if (b43_is_cck_rate(bitrate) && phy->type != B43_PHYTYPE_LP) {
+		control = bw;
+	} else {
+		control = bw;
+		e = b43_tx_legacy_rate_phy_ctl_ent(bitrate);
+		if (e) {
+			control |= e->coding_rate;
+			control |= e->modulation;
+		}
+		control |= B43_TXH_PHY1_MODE_SISO;
+	}
+
+	return control;
+}
+
 static u8 b43_calc_fallback_rate(u8 bitrate)
 {
 	switch (bitrate) {
@@ -437,6 +495,14 @@ int b43_generate_txhdr(struct b43_wldev *dev,
 			extra_ft |= B43_TXH_EFT_RTSFB_OFDM;
 		else
 			extra_ft |= B43_TXH_EFT_RTSFB_CCK;
+
+		if (rates[0].flags & IEEE80211_TX_RC_USE_RTS_CTS &&
+		    phy->type == B43_PHYTYPE_N) {
+			txhdr->phy_ctl1_rts = cpu_to_le16(
+				b43_generate_tx_phy_ctl1(dev, rts_rate));
+			txhdr->phy_ctl1_rts_fb = cpu_to_le16(
+				b43_generate_tx_phy_ctl1(dev, rts_rate_fb));
+		}
 	}
 
 	/* Magic cookie */
@@ -445,6 +511,13 @@ int b43_generate_txhdr(struct b43_wldev *dev,
 	else
 		txhdr->new_format.cookie = cpu_to_le16(cookie);
 
+	if (phy->type == B43_PHYTYPE_N) {
+		txhdr->phy_ctl1 =
+			cpu_to_le16(b43_generate_tx_phy_ctl1(dev, rate));
+		txhdr->phy_ctl1_fb =
+			cpu_to_le16(b43_generate_tx_phy_ctl1(dev, rate_fb));
+	}
+
 	/* Apply the bitfields */
 	txhdr->mac_ctl = cpu_to_le32(mac_ctl);
 	txhdr->phy_ctl = cpu_to_le16(phy_ctl);
diff --git a/drivers/net/wireless/b43/xmit.h b/drivers/net/wireless/b43/xmit.h
index d4cf9b3..42debb5 100644
--- a/drivers/net/wireless/b43/xmit.h
+++ b/drivers/net/wireless/b43/xmit.h
@@ -73,6 +73,12 @@ struct b43_txhdr {
 	} __packed;
 } __packed;
 
+struct b43_tx_legacy_rate_phy_ctl_entry {
+	u8 bitrate;
+	u16 coding_rate;
+	u16 modulation;
+};
+
 /* MAC TX control */
 #define B43_TXH_MAC_USEFBR		0x10000000 /* Use fallback rate for this AMPDU */
 #define B43_TXH_MAC_KEYIDX		0x0FF00000 /* Security key index */
-- 
1.7.3.4



From zajec5 at gmail.com  Fri Feb 25 06:38:27 2011
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Fri, 25 Feb 2011 12:38:27 +0100
Subject: [PATCH] b43: fill PHY ctl word1 in TX header for N-PHY
In-Reply-To: <1298633651-5641-1-git-send-email-zajec5@gmail.com>
References: <1298633651-5641-1-git-send-email-zajec5@gmail.com>
Message-ID: <AANLkTikC12gTdFpkC4VFkw-Q5w4Zg3AsHbpNqnu-DQda@mail.gmail.com>

W dniu 25 lutego 2011 12:34 u?ytkownik Rafa? Mi?ecki <zajec5 at gmail.com> napisa?:
> + ? ? ? if (phy->type == B43_PHYTYPE_LP)
> + ? ? ? ? ? ? ? bw = B43_TXH_PHY1_BW_20;

(...)

> + ? ? ? if (phy->type == B43_PHYTYPE_N) {
> + ? ? ? ? ? ? ? txhdr->phy_ctl1 =
> + ? ? ? ? ? ? ? ? ? ? ? cpu_to_le16(b43_generate_tx_phy_ctl1(dev, rate));
> + ? ? ? ? ? ? ? txhdr->phy_ctl1_fb =
> + ? ? ? ? ? ? ? ? ? ? ? cpu_to_le16(b43_generate_tx_phy_ctl1(dev, rate_fb));
> + ? ? ? }

Just to make it clear: this TX header is expected to be filled on
both: LP-PHY and N-PHY - that's why you can see some LP specific code
in filling function. It just was not tested yet on LP-PHY, that's why
it is still disabled.

-- 
Rafa?


