Re: 4311 works with fedora 7 but only at 1mb/s

2007-08-14 Thread Larry Finger
John H. wrote:
> It seemed it had a more difficult time changing at one location 1.5
> hours away with a different AP than the one i am back on now.  right
> now it is up to 48mb/s automatically.
> 
> Is it safe to assume future releases of f7 kernel rpm will have a
> workable driver such as -50 from rawhide does?

I cannot speak for Fedora's kernel update policy. The changes that have been 
incorporated into the 
Rawhide kernels are now in the wireless-dev tree, and will become part of 
mainline eventually. Those 
changes will certainly be a part of F8.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: 4311 works with fedora 7 but only at 1mb/s

2007-08-14 Thread John H.
It seemed it had a more difficult time changing at one location 1.5
hours away with a different AP than the one i am back on now.  right
now it is up to 48mb/s automatically.

Is it safe to assume future releases of f7 kernel rpm will have a
workable driver such as -50 from rawhide does?

On 8/14/07, Larry Finger <[EMAIL PROTECTED]> wrote:
> John H. wrote:
> > I spoke too soon.  I just tried it again and it seemed stuck on 1 mb/s
> > and there was an obvious difference in network speed.  hmm.
>
> If you don't want the auto speed adjustment, or are unhappy with it, you can 
> change the rate setting
> with the 'iwconfig eth1 rate Y' command. As your system seems not to 
> auto-scale very well, I would
> try values for Y of 11M, 18M, 24M, 36M, 48M, and 54M (in that order). For 
> each speed, try a ping
> flood against your AP (ping -f 192.168.1.1, or whatever address is shown as 
> the gateway in a 'route
> -n' command). As long as you don't see a lot of dots from the flood, it is 
> safe to try the next
> higher speed. Once you get a failure, you might want to back off one extra 
> speed for safety.
>
> Have you tried changing the AP's channel, if possible? You might find less 
> interference with a
> different setting. Does your location have any other 2.4 GHz devices like 
> portable telephones or
> baby monitors, etc. They could interfere.
>
> Larry
>
>
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Linksys N card (4329)... is this an RE project...

2007-08-14 Thread Larry Finger
Ehud Gavron wrote:
> I have a Linksys PCMCIA N card which IDs as a BCM43XG, but unfortunately 
> is model 0x4329 rev 01, which is not on the hardware list as a supported 
> device.
> Is this something that requires RE effort... and am I tainted because 
> I've looked at the Linux driver (reverse tainted) or am I clear... but 
> if I start doing RE I can never contribute to the driver code?

Unofficially, my opinion is as follows:

1. Your looking at the current driver does not taint you regarding Broadcom's 
intellectual property.

2. Once you have worked on the decompiled Broadcom drivers, you cannot 
contribute code to our 
driver. That would breach the clean-room isolation. You are still allowed to 
test and to report 
deficiencies, but not suggest fixes.

I have no knowledge of the status of the RE of the 802.11n devices. There is 
some info regarding 
these devices in the V4 specs, but AFAIK, none of these have been coded. We've 
been busy getting 
802.11g code working.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Linksys N card (4329)... is this an RE project...

2007-08-14 Thread Ehud Gavron
I have a Linksys PCMCIA N card which IDs as a BCM43XG, but unfortunately 
is model 0x4329 rev 01, which is not on the hardware list as a supported 
device.
Is this something that requires RE effort... and am I tainted because 
I've looked at the Linux driver (reverse tainted) or am I clear... but 
if I start doing RE I can never contribute to the driver code?


Thanks,

Ehud


Latest "everything" kernel.

dmesg with b43 and normal firmware: [nothing]
dmesg with b43 and firmware from the Linksys file that came with it: 
[nothing]
dmesg with bcm43xx fwpostfix=".fw3" (I didn't expect it to work, but 
tried for completeness": bcm43xx driver


uname -a: Linux techeg.login.com 2.6.23-rc3 #1 SMP Tue Aug 14 17:28:00 
MST 2007 1686 1686 i386 GNU/Linux


lspci: 06:00.0 0280: 14e4:4329 (rev 01)



smime.p7s
Description: S/MIME Cryptographic Signature
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[PATCH] b43: Kconfig indentation not right

2007-08-14 Thread Larry Finger
The indentation (dependencies) are not right for B43.

Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---

Index: wireless-dev/drivers/net/wireless/b43/Kconfig
===
--- wireless-dev.orig/drivers/net/wireless/b43/Kconfig
+++ wireless-dev/drivers/net/wireless/b43/Kconfig
@@ -11,14 +11,14 @@ config B43
 # Auto-select SSB PCI-HOST support, if possible
 config B43_PCI_AUTOSELECT
bool
-   depends on SSB_PCIHOST_POSSIBLE
+   depends on SSB_PCIHOST_POSSIBLE && B43
select SSB_PCIHOST
default y
 
 # Auto-select SSB PCICORE driver, if possible
 config B43_PCICORE_AUTOSELECT
bool
-   depends on SSB_DRIVER_PCICORE_POSSIBLE
+   depends on SSB_DRIVER_PCICORE_POSSIBLE && B43
select SSB_DRIVER_PCICORE
default y
 
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [patch 0/7] SSB: New patch series for merge

2007-08-14 Thread Larry Finger
Michael Buesch wrote:
> On Tuesday 14 August 2007 19:34:08 Larry Finger wrote:
>> Michael Buesch wrote:
>>> Hi John,
>>>
>>> This patch series catches SSB up to my
>>> current wireless-development patchset.
>>>
>>> Please merge this into wireless-dev ssb branch.
>> I had a problem with #7. My copy of John's tree still has EXPERIMENTAL for 
>> ssb. Yours does not.
> 
> Are you sure you have latest wireless-dev? It has
> been rebased again.
> 

Indeed, that was the problem. Once I got John's email and learned how to handle 
the new rebase, you 
patch applied just fine.

Larry


___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Dell 1390 not detecting AP

2007-08-14 Thread Larry Finger
Andrew McGuinness wrote:
> I'm not able to detect my AP with a Dell 1390 mini-pci using bcm43xx
> 
> I appreciate that the driver is under very heavy development at the
> moment, and I'm willing to try the bcm43 if that will help.
> 
> 
> The "radio disabled by hardware" looks like a problem to me   ?

That is a killer and usually means that the wireless device switch is off. So 
far, we have found no 
devices where that can be controlled by software.

What is the make/model of your laptop? What kind of switch does it have to 
enable the wireless?

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Dell 1390 not detecting AP

2007-08-14 Thread Andrew McGuinness
Ehud Gavron wrote:
> ifconfig eth1 up
> 
> E
> 

No, I did that.  It didn't complain, but it didn't do anything either

$ ifconfig eth1 up
$ ifconfig eth1

eth1  Link encap:Ethernet  HWaddr 00:19:7E:41:C1:B4
  UP BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:611 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 b)  TX bytes:25662 (25.0 KiB)
  Interrupt:11 Base address:0x8000

$ iwlist eth1 scan
Warning: Driver for device eth1 has been compiled with version 22
of Wireless Extension, while this program supports up to version 20.
Some things may be broken...

eth1 No scan results



> Andrew McGuinness wrote:
>> I'm not able to detect my AP with a Dell 1390 mini-pci using bcm43xx
>>
>> I appreciate that the driver is under very heavy development at the
>> moment, and I'm willing to try the bcm43 if that will help.
>>
>> Details follow:
>>
>>
>> The Acer Aspire 3680 contains the following (lspci -v)
>>
>> 03:00.0 Network controller: Broadcom Corporation Dell Wireless 1390 WLAN
>> Mini-PCI Card (rev 01)
>> Subsystem: AMBIT Microsystem Corp. Unknown device 0422
>> Flags: bus master, fast devsel, latency 0, IRQ 17
>> Memory at 3410 (32-bit, non-prefetchable) [size=16K]
>> Capabilities: [40] Power Management version 2
>> Capabilities: [58] Message Signalled Interrupts: Mask- 64bit-
>> Queue=0/0
>> Enable-
>> Capabilities: [d0] Express Legacy Endpoint IRQ 0
>> Capabilities: [100] Advanced Error Reporting
>> Capabilities: [13c] Virtual Channel
>>
>> and from lspci -n
>>
>> 03:00.0 0280: 14e4:4311 (rev 01)
>>
>>
>> I built a 2.6.21 kernel from debian, with the combined_2.6.21.patch from
>>  lwfinger.dynalias.org
>>
>> I got the v3 firmware wl_apsta-3.130.20.0.o and used fwcutter to create
>> the .fw files in /lib/firmware
>>
>> $ dmesg | grep bcm
>>
>> bcm43xx driver
>> bcm43xx: Chip ID 0x4311, rev 0x1
>> bcm43xx: Number of cores: 4
>> bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243
>> bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243
>> bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243
>> bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243
>> bcm43xx: PHY connected
>> bcm43xx: Detected PHY: Analog: 4, Type 2, Revision 8
>> bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
>> bcm43xx: Radio turned off
>> bcm43xx: Radio turned off
>> bcm43xx: PHY connected
>> bcm43xx: Microcode rev 0x127, pl 0xe (2005-04-18  02:36:27)
>> bcm43xx: Radio turned on
>> bcm43xx: Radio disabled by hardware
>> bcm43xx: Chip initialized
>> bcm43xx: 32-bit DMA initialized
>> bcm43xx: Keys cleared
>> bcm43xx: Selected 802.11 core (phytype 2)
>> bcm43xx: set security called, .level = 0, .enabled = 0, .encrypt = 0
>>
>> $ iwconfig eth1 essid arobeia
>>
>> $ iwconfig eth1
>>
>> Warning: Driver for device eth1 has been compiled with version 22
>> of Wireless Extension, while this program supports up to version 20.
>> Some things may be broken...
>>
>> eth1  IEEE 802.11b/g  ESSID:"arobeia"  Nickname:"Broadcom 4311"
>>   Mode:Managed  Frequency=2.472 GHz  Access Point: Invalid
>>   Bit Rate=1 Mb/s   Tx-Power=18 dBm
>>   RTS thr:off   Fragment thr:off
>>   Encryption key:off
>>   Link Quality=0/100  Signal level=-256 dBm  Noise level=-256 dBm
>>   Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>>   Tx excessive retries:0  Invalid misc:0   Missed beacon:0
>>
>>
>>
>> $ iwlist eth1 scan
>>
>> eth1 no scan results
>>
>> The "radio disabled by hardware" looks like a problem to me   ?
>>
>>
>>   

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Dell 1390 not detecting AP

2007-08-14 Thread Ehud Gavron

ifconfig eth1 up

E

Andrew McGuinness wrote:

I'm not able to detect my AP with a Dell 1390 mini-pci using bcm43xx

I appreciate that the driver is under very heavy development at the
moment, and I'm willing to try the bcm43 if that will help.

Details follow:


The Acer Aspire 3680 contains the following (lspci -v)

03:00.0 Network controller: Broadcom Corporation Dell Wireless 1390 WLAN
Mini-PCI Card (rev 01)
Subsystem: AMBIT Microsystem Corp. Unknown device 0422
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at 3410 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 2
Capabilities: [58] Message Signalled Interrupts: Mask- 64bit- Queue=0/0
Enable-
Capabilities: [d0] Express Legacy Endpoint IRQ 0
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Virtual Channel

and from lspci -n

03:00.0 0280: 14e4:4311 (rev 01)


I built a 2.6.21 kernel from debian, with the combined_2.6.21.patch from
 lwfinger.dynalias.org

I got the v3 firmware wl_apsta-3.130.20.0.o and used fwcutter to create
the .fw files in /lib/firmware

$ dmesg | grep bcm

bcm43xx driver
bcm43xx: Chip ID 0x4311, rev 0x1
bcm43xx: Number of cores: 4
bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243
bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243
bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243
bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243
bcm43xx: PHY connected
bcm43xx: Detected PHY: Analog: 4, Type 2, Revision 8
bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
bcm43xx: Radio turned off
bcm43xx: Radio turned off
bcm43xx: PHY connected
bcm43xx: Microcode rev 0x127, pl 0xe (2005-04-18  02:36:27)
bcm43xx: Radio turned on
bcm43xx: Radio disabled by hardware
bcm43xx: Chip initialized
bcm43xx: 32-bit DMA initialized
bcm43xx: Keys cleared
bcm43xx: Selected 802.11 core (phytype 2)
bcm43xx: set security called, .level = 0, .enabled = 0, .encrypt = 0

$ iwconfig eth1 essid arobeia

$ iwconfig eth1

Warning: Driver for device eth1 has been compiled with version 22
of Wireless Extension, while this program supports up to version 20.
Some things may be broken...

eth1  IEEE 802.11b/g  ESSID:"arobeia"  Nickname:"Broadcom 4311"
  Mode:Managed  Frequency=2.472 GHz  Access Point: Invalid
  Bit Rate=1 Mb/s   Tx-Power=18 dBm
  RTS thr:off   Fragment thr:off
  Encryption key:off
  Link Quality=0/100  Signal level=-256 dBm  Noise level=-256 dBm
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:0   Missed beacon:0



$ iwlist eth1 scan

eth1 no scan results

The "radio disabled by hardware" looks like a problem to me   ?


  


smime.p7s
Description: S/MIME Cryptographic Signature
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Dell 1390 not detecting AP

2007-08-14 Thread Andrew McGuinness
I'm not able to detect my AP with a Dell 1390 mini-pci using bcm43xx

I appreciate that the driver is under very heavy development at the
moment, and I'm willing to try the bcm43 if that will help.

Details follow:


The Acer Aspire 3680 contains the following (lspci -v)

03:00.0 Network controller: Broadcom Corporation Dell Wireless 1390 WLAN
Mini-PCI Card (rev 01)
Subsystem: AMBIT Microsystem Corp. Unknown device 0422
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at 3410 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 2
Capabilities: [58] Message Signalled Interrupts: Mask- 64bit- Queue=0/0
Enable-
Capabilities: [d0] Express Legacy Endpoint IRQ 0
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Virtual Channel

and from lspci -n

03:00.0 0280: 14e4:4311 (rev 01)


I built a 2.6.21 kernel from debian, with the combined_2.6.21.patch from
 lwfinger.dynalias.org

I got the v3 firmware wl_apsta-3.130.20.0.o and used fwcutter to create
the .fw files in /lib/firmware

$ dmesg | grep bcm

bcm43xx driver
bcm43xx: Chip ID 0x4311, rev 0x1
bcm43xx: Number of cores: 4
bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243
bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243
bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243
bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243
bcm43xx: PHY connected
bcm43xx: Detected PHY: Analog: 4, Type 2, Revision 8
bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
bcm43xx: Radio turned off
bcm43xx: Radio turned off
bcm43xx: PHY connected
bcm43xx: Microcode rev 0x127, pl 0xe (2005-04-18  02:36:27)
bcm43xx: Radio turned on
bcm43xx: Radio disabled by hardware
bcm43xx: Chip initialized
bcm43xx: 32-bit DMA initialized
bcm43xx: Keys cleared
bcm43xx: Selected 802.11 core (phytype 2)
bcm43xx: set security called, .level = 0, .enabled = 0, .encrypt = 0

$ iwconfig eth1 essid arobeia

$ iwconfig eth1

Warning: Driver for device eth1 has been compiled with version 22
of Wireless Extension, while this program supports up to version 20.
Some things may be broken...

eth1  IEEE 802.11b/g  ESSID:"arobeia"  Nickname:"Broadcom 4311"
  Mode:Managed  Frequency=2.472 GHz  Access Point: Invalid
  Bit Rate=1 Mb/s   Tx-Power=18 dBm
  RTS thr:off   Fragment thr:off
  Encryption key:off
  Link Quality=0/100  Signal level=-256 dBm  Noise level=-256 dBm
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:0   Missed beacon:0



$ iwlist eth1 scan

eth1 no scan results

The "radio disabled by hardware" looks like a problem to me   ?


-- 
Andrew McGuinness

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


wireless-dev rebased, new rebasing policies

2007-08-14 Thread John W. Linville
Greetings!

Some of you have already noticed that the wireless-dev tree has
been rebased.  I adopted the mac80211 work of Jiri Benc as a base,
then re-imported all of the mac80211 drivers (and the SSB stuff) from
wireless-dev into individual branches.  There is also an 'everything'
branch into which all the other branches get pulled, and an 'mm-master'
branch which has the sole purpose of feeding patches to akpm while
minimizing conflicts with the other networking trees.  The master
branch is a direct pull of something relatively recent from Linus,
usually an -rc or release tag.

Recent versions of git seem to hide remote branches by default when
cloning a tree, so by default you will just get my master branch.
Since this isn't very interesting for wireless development, you will
want to recreate one or more of my branches to work from as a base.

At a minimum, everyone from "early adopter" users to driver maintainers
will want the 'everything' branch, so I will illustrate recreating
that below.  Other branches are done similarly.

/home/linville/git/wireless-dev
[linville-t43.mobile]:> git branch
* master

/home/linville/git/wireless-dev
[linville-t43.mobile]:> git branch -r
  origin/HEAD
  origin/adm8211
  origin/b43
  origin/everything
  origin/iwlwifi
  origin/mac80211
  origin/master
  origin/merged-upstream
  origin/mm-master
  origin/p54
  origin/rt2x00
  origin/ssb
  origin/zd1211rw

/home/linville/git/wireless-dev
[linville-t43.mobile]:> git checkout -b everything origin/everything
Switched to a new branch "everything"

/home/linville/git/wireless-dev
[linville-t43.mobile]:> git branch
* everything
  master

Unlike the way wireless-dev was used in the past, I make no promises
about rebasing.  I intend to rebase most/all of the branches at least
as often as Linus produces an -rc or release tag, and I reserve the
right to rebase more often as I deem necessary.  I'm sorry, but as
you can see I have to manage a lot of patches.  Keeping them based
off a recent head is helpful to me.

I will entertain suggestions for how to minimize rebasing pain for
anyone following this tree.  However, the best suggestion I have
for anyone tracking wireless-dev is for them to get their favorite
driver(s) merged upstream.  Barring that, I understand that quilt
can be a good tool for tracking stacks of patches in development.
The git-format-patch, git-applymbox, and git-rebase commands are
handy as well.

Those simply following the tree should learn about the "--reference"
option to git-clone, and should use it often.  Keeping a backup of
previous git trees with any work in progress wouldn't hurt either.

Questions?  Complaints?  Comments?

Thanks,

John
-- 
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[patch 8/9] b43: Fix controller reset

2007-08-14 Thread Michael Buesch
Don't check the device status. It's checked and handled later in
the workqueue. Use proper locking in the reset callback.

Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: wireless-dev-new/drivers/net/wireless/b43/main.c
===
--- wireless-dev-new.orig/drivers/net/wireless/b43/main.c   2007-08-13 
17:44:34.0 +0200
+++ wireless-dev-new/drivers/net/wireless/b43/main.c2007-08-13 
18:13:13.0 +0200
@@ -2539,14 +2539,16 @@ static int b43_get_stats(struct ieee8021
 static int b43_dev_reset(struct ieee80211_hw *hw)
 {
struct b43_wl *wl = hw_to_b43_wl(hw);
-   struct b43_wldev *dev = wl->current_dev;
-   unsigned long flags;
+   struct b43_wldev *dev;
+   int err = -ENODEV;
 
-   if (!dev)
-   return -ENODEV;
-   spin_lock_irqsave(&wl->irq_lock, flags);
-   b43_controller_restart(dev, "Reset by ieee80211 subsystem");
-   spin_unlock_irqrestore(&wl->irq_lock, flags);
+   mutex_lock(&wl->mutex);
+   dev = wl->current_dev;
+   if (dev) {
+   b43_controller_restart(dev, "Reset by ieee80211 subsystem");
+   err = 0;
+   }
+   mutex_unlock(&wl->mutex);
 
return 0;
 }
@@ -3911,14 +3913,9 @@ static void b43_remove(struct ssb_device
}
 }
 
-/* Hard-reset the chip.
- * This can be called from interrupt or process context.
- * dev->irq_lock must be locked.
- */
+/* Perform a hardware reset. This can be called from any context. */
 void b43_controller_restart(struct b43_wldev *dev, const char *reason)
 {
-   if (b43_status(dev) != B43_STAT_INITIALIZED)
-   return;
bcminfo(dev->wl, "Controller RESET (%s) ...\n", reason);
queue_work(dev->wl->hw->workqueue, &dev->restart_work);
 }

-- 

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[patch 2/9] b43: Remove PCI to SSB bridge code

2007-08-14 Thread Michael Buesch
This will be added to ssb

Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: wireless-dev-new/drivers/net/wireless/b43/main.c
===
--- wireless-dev-new.orig/drivers/net/wireless/b43/main.c   2007-08-12 
16:38:52.0 +0200
+++ wireless-dev-new/drivers/net/wireless/b43/main.c2007-08-12 
20:12:24.0 +0200
@@ -104,7 +104,11 @@ module_param_named(hwpctl, modparam_hwpc
 MODULE_PARM_DESC(hwpctl, "Enable hardware-side power control (default off)");
 
 static const struct ssb_device_id b43_ssb_tbl[] = {
-   SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, SSB_ANY_REV),
+   SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 5),
+   SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 6),
+   SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 7),
+   SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 9),
+   SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_80211, 10),
SSB_DEVTABLE_END
 };
 
@@ -3959,67 +3963,35 @@ static int b43_resume(struct ssb_device 
 
 #else /* CONFIG_PM */
 # define b43_suspend   NULL
-# define b43_resumeNULL
+# define b43_resumeNULL
 #endif /* CONFIG_PM */
 
 static struct ssb_driver b43_ssb_driver = {
-   .name = KBUILD_MODNAME,
-   .id_table = b43_ssb_tbl,
-   .probe = b43_probe,
-   .remove = b43_remove,
-   .suspend = b43_suspend,
-   .resume = b43_resume,
+   .name   = KBUILD_MODNAME,
+   .id_table   = b43_ssb_tbl,
+   .probe  = b43_probe,
+   .remove = b43_remove,
+   .suspend= b43_suspend,
+   .resume = b43_resume,
 };
 
-#ifdef CONFIG_B43_PCI
-/* The PCI frontend stub */
-static const struct pci_device_id b43_pci_tbl[] = {
-   {PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4307)},
-   {PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4311)},
-   {PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4312)},
-   {PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4318)},
-   {PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4319)},
-   {PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4320)},
-   {PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4321)},
-   {PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324)},
-   {PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4325)},
-   {0},
-};
-
-MODULE_DEVICE_TABLE(pci, b43_pci_tbl);
-
-static struct pci_driver b43_pci_driver = {
-   .name = "b43-pci",
-   .id_table = b43_pci_tbl,
-};
-#endif /* CONFIG_B43_PCI */
-
 static int __init b43_init(void)
 {
int err;
 
b43_debugfs_init();
-#ifdef CONFIG_B43_PCI
-   err = ssb_pcihost_register(&b43_pci_driver);
-   if (err)
-   goto err_dfs_exit;
-#endif
err = b43_pcmcia_init();
if (err)
-   goto err_pci_exit;
+   goto err_dfs_exit;
err = ssb_driver_register(&b43_ssb_driver);
if (err)
goto err_pcmcia_exit;
 
return err;
 
-  err_pcmcia_exit:
+err_pcmcia_exit:
b43_pcmcia_exit();
-  err_pci_exit:
-#ifdef CONFIG_B43_PCI
-   ssb_pcihost_unregister(&b43_pci_driver);
-#endif
-  err_dfs_exit:
+err_dfs_exit:
b43_debugfs_exit();
return err;
 }
@@ -4028,11 +4000,8 @@ static void __exit b43_exit(void)
 {
ssb_driver_unregister(&b43_ssb_driver);
b43_pcmcia_exit();
-#ifdef CONFIG_B43_PCI
-   ssb_pcihost_unregister(&b43_pci_driver);
-#endif
b43_debugfs_exit();
 }
 
 module_init(b43_init)
-module_exit(b43_exit)
+module_exit(b43_exit)

-- 

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[patch 3/9] b43: Powerup the bus before accessing any MMIO

2007-08-14 Thread Michael Buesch
This crashes otherwise.

Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: wireless-dev-new/drivers/net/wireless/b43/main.c
===
--- wireless-dev-new.orig/drivers/net/wireless/b43/main.c   2007-08-12 
20:17:01.0 +0200
+++ wireless-dev-new/drivers/net/wireless/b43/main.c2007-08-12 
20:17:07.0 +0200
@@ -3619,6 +3619,11 @@ static int b43_wireless_core_attach(stru
 * that in core_init(), too.
 */
 
+   err = ssb_bus_powerup(bus, 0);
+   if (err) {
+   bcmerr(wl, "Bus powerup failed\n");
+   goto out;
+   }
/* Get the PHY type. */
if (dev->dev->id.revision >= 5) {
u32 tmshigh;
@@ -3637,7 +3642,7 @@ static int b43_wireless_core_attach(stru
/* Initialize LEDs structs. */
err = b43_leds_init(dev);
if (err)
-   goto out;
+   goto err_powerdown;
 
dev->phy.gmode = (have_gphy || have_bphy);
tmp = dev->phy.gmode ? B43_TMSLOW_GMODE : 0;
@@ -3689,11 +3694,13 @@ static int b43_wireless_core_attach(stru
ssb_device_disable(dev->dev, 0);
ssb_bus_may_powerdown(bus);
 
-  out:
+out:
return err;
 
-  err_leds_exit:
+err_leds_exit:
b43_leds_exit(dev);
+err_powerdown:
+   ssb_bus_may_powerdown(bus);
return err;
 }
 

-- 

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[patch 9/9] b43: Rewrite kconfig to get rid of the advice hack.

2007-08-14 Thread Michael Buesch
This should properly autoselect the SSB options without
introducing a dependency hell.

Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: wireless-dev-new/drivers/net/wireless/b43/Kconfig
===
--- wireless-dev-new.orig/drivers/net/wireless/b43/Kconfig  2007-08-14 
20:09:15.0 +0200
+++ wireless-dev-new/drivers/net/wireless/b43/Kconfig   2007-08-14 
20:11:07.0 +0200
@@ -1,49 +1,31 @@
-config B43_DEP_HACK
-   bool
-   depends on SSB && SSB_PCIHOST && SSB_DRIVER_PCICORE
-   default y
-
-config B43_ADVICE_HACK
-   bool "Broadcom 43xx PCI (mac80211) not available. Read the help text of 
this option!"
-   depends on !B43_DEP_HACK
-   ---help---
- The B43 driver for B43 PCI devices can not be enabled,
- because the required dependencies are not selected.
-
- In order to be able to select the B43-mac80211 driver, you
- need to enable the following options first:
-
- CONFIG_SSB found in menu:
- Device Drivers/Sonics Silicon Backplane/Sonics Silicon Backplane 
support
- CONFIG_SSB_PCIHOST found in menu:
- Device Drivers/Sonics Silicon Backplane/Support for SSB on PCI-bus 
host
- CONFIG_SSB_DRIVER_PCICORE found in menu:
- Device Drivers/Sonics Silicon Backplane/SSB PCI core driver
-
 config B43
tristate "Broadcom 43xx wireless support (mac80211 stack)"
-   depends on SSB && MAC80211 && WLAN_80211 && EXPERIMENTAL
+   depends on SSB_POSSIBLE && MAC80211 && WLAN_80211 && EXPERIMENTAL
+   select SSB
select FW_LOADER
select HW_RANDOM
---help---
  This is an experimental driver for the Broadcom 43xx wireless chip,
  found in the Apple Airport Extreme and various other devices.
 
-config B43_PCI
-   bool "Broadcom 43xx PCI device support"
-   depends on B43 && SSB_PCIHOST && SSB_DRIVER_PCICORE
+# Auto-select SSB PCI-HOST support, if possible
+config B43_PCI_AUTOSELECT
+   bool
+   depends on SSB_PCIHOST_POSSIBLE
+   select SSB_PCIHOST
default y
-   ---help---
- Broadcom 43xx PCI device support.
 
- Say Y, if you have a B43 device connected through the PCI bus.
- Please note that most PC-CARD devices are (to the kernel) PCI devices,
- too and not PCMCIA.
- It's safe to select Y here, even if you don't have a B43 PCI device.
+# Auto-select SSB PCICORE driver, if possible
+config B43_PCICORE_AUTOSELECT
+   bool
+   depends on SSB_DRIVER_PCICORE_POSSIBLE
+   select SSB_DRIVER_PCICORE
+   default y
 
 config B43_PCMCIA
bool "Broadcom 43xx PCMCIA device support"
-   depends on B43 && SSB_PCMCIAHOST
+   depends on B43 && SSB_PCMCIAHOST_POSSIBLE
+   select SSB_PCMCIAHOST
---help---
  Broadcom 43xx PCMCIA device support.
 

-- 

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[patch 1/9] b43: Add more LO debugging

2007-08-14 Thread Michael Buesch
This makes it possible to find uses of uncalibrated LO value pairs.

Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: wireless-dev-new/drivers/net/wireless/b43/lo.c
===
--- wireless-dev-new.orig/drivers/net/wireless/b43/lo.c 2007-08-14 
20:09:16.0 +0200
+++ wireless-dev-new/drivers/net/wireless/b43/lo.c  2007-08-14 
20:09:27.0 +0200
@@ -986,6 +986,8 @@ static void lo_measure(struct b43_wldev 
continue;
}
memcpy(&loctl, ploctl, sizeof(loctl));
+   loctl.i = 0;
+   loctl.q = 0;
 
max_rx_gain = lo->rfatt_list.list[rfidx].att * 2;
max_rx_gain += lo->bbatt_list.list[bbidx].att / 2;
@@ -1004,6 +1006,7 @@ static void lo_measure(struct b43_wldev 
loctl.i++;
loctl.q++;
}
+   b43_loctl_set_calibrated(&loctl, 1);
memcpy(ploctl, &loctl, sizeof(loctl));
}
}
@@ -1013,23 +1016,58 @@ static void lo_measure(struct b43_wldev 
 static void do_validate_loctl(struct b43_wldev *dev, struct b43_loctl *control)
 {
const int is_initializing = (b43_status(dev) == B43_STAT_UNINIT);
+   int i = control->i;
+   int q = control->q;
 
-   if (unlikely(abs(control->i) > 16 ||
-abs(control->q) > 16 ||
-(is_initializing && control->used))) {
-   bcmdbg(dev->wl, "ERROR: LO control pair validation failed "
-  "(first: %d, second: %d, used %u)\n",
-  control->i, control->q, control->used);
+   if (b43_loctl_is_calibrated(control)) {
+   if ((abs(i) > 16) || (abs(q) > 16))
+   goto error;
+   } else {
+   if (control->used)
+   goto error;
+   if (dev->phy.lo_control->rebuild) {
+   control->i = 0;
+   control->q = 0;
+   if ((i != B43_LOCTL_POISON) ||
+   (q != B43_LOCTL_POISON))
+   goto error;
+   }
}
+   if (is_initializing && control->used)
+   goto error;
+
+   return;
+error:
+   bcmerr(dev->wl, "LO control pair validation failed "
+  "(I: %d, Q: %d, used %u, calib: %u, initing: %d)\n",
+  i, q, control->used,
+  b43_loctl_is_calibrated(control),
+  is_initializing);
 }
+
 static void validate_all_loctls(struct b43_wldev *dev)
 {
b43_call_for_each_loctl(dev, do_validate_loctl);
 }
-#else /* B43_DEBUG */
-static inline void validate_all_loctls(struct b43_wldev *dev)
+
+static void do_reset_calib(struct b43_wldev *dev, struct b43_loctl *control)
 {
+   if (dev->phy.lo_control->rebuild ||
+   control->used) {
+   b43_loctl_set_calibrated(control, 0);
+   control->i = B43_LOCTL_POISON;
+   control->q = B43_LOCTL_POISON;
+   }
 }
+
+static void reset_all_loctl_calibration_states(struct b43_wldev *dev)
+{
+   b43_call_for_each_loctl(dev, do_reset_calib);
+}
+
+#else /* B43_DEBUG */
+static inline void validate_all_loctls(struct b43_wldev *dev) { }
+static inline void reset_all_loctl_calibration_states(struct b43_wldev *dev) { 
}
 #endif /* B43_DEBUG */
 
 void b43_lo_g_measure(struct b43_wldev *dev)
@@ -1042,6 +1080,7 @@ void b43_lo_g_measure(struct b43_wldev *
 
sav.old_channel = phy->channel;
lo_measure_setup(dev, &sav);
+   reset_all_loctl_calibration_states(dev);
lo_measure(dev);
lo_measure_restore(dev, &sav);
 
@@ -1051,10 +1090,33 @@ void b43_lo_g_measure(struct b43_wldev *
phy->lo_control->rebuild = 0;
 }
 
-void b43_lo_g_adjust(struct b43_wldev *dev)
+#if B43_DEBUG
+static void validate_loctl_calibration(struct b43_wldev *dev,
+  struct b43_loctl *loctl,
+  struct b43_rfatt *rfatt,
+  struct b43_bbatt *bbatt)
+{
+   if (b43_loctl_is_calibrated(loctl))
+   return;
+   if (!dev->phy.lo_control->lo_measured) {
+   /* On init we set the attenuation values before we
+* calibrated the LO. I guess that's OK. */
+   return;
+   }
+   bcmerr(dev->wl, "Adjusting Local Oscillator to an uncalibrated "
+  "control pair: rfatt=%u,%spadmix bbatt=%u\n",
+  rfatt->att,
+  (rfatt->with_padmix) ? "" : "no-",
+  bbatt->att);
+}
+#else
+static inline void validate_loctl_calibration(struct b43_wldev *dev,
+ struct b43_loctl *loctl,
+ s

[patch 4/9] b43: Check init status in b43_config_interface.

2007-08-14 Thread Michael Buesch
We must check for >=INITIALIZED

Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: wireless-dev-new/drivers/net/wireless/b43/main.c
===
--- wireless-dev-new.orig/drivers/net/wireless/b43/main.c   2007-08-12 
20:17:07.0 +0200
+++ wireless-dev-new/drivers/net/wireless/b43/main.c2007-08-12 
20:17:11.0 +0200
@@ -2940,13 +2940,15 @@ static int b43_config_interface(struct i
if (conf->type != IEEE80211_IF_TYPE_MNTR) {
B43_WARN_ON(wl->if_id != if_id);
wl->bssid = conf->bssid;
-   if (b43_is_mode(wl, IEEE80211_IF_TYPE_AP)) {
-   B43_WARN_ON(conf->type != IEEE80211_IF_TYPE_AP);
-   b43_set_ssid(dev, conf->ssid, conf->ssid_len);
-   if (conf->beacon)
-   b43_refresh_templates(dev, conf->beacon);
+   if (b43_status(dev) >= B43_STAT_INITIALIZED) {
+   if (b43_is_mode(wl, IEEE80211_IF_TYPE_AP)) {
+   B43_WARN_ON(conf->type != IEEE80211_IF_TYPE_AP);
+   b43_set_ssid(dev, conf->ssid, conf->ssid_len);
+   if (conf->beacon)
+   b43_refresh_templates(dev, 
conf->beacon);
+   }
+   b43_write_mac_bssid_templates(dev);
}
-   b43_write_mac_bssid_templates(dev);
}
spin_unlock_irqrestore(&wl->irq_lock, flags);
mutex_unlock(&wl->mutex);

-- 

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[patch 7/9] b43: Fix frame retry count for suppressed frames

2007-08-14 Thread Michael Buesch
(u8)0 - 1 == 255
which is wrong. Should be 0.

Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: wireless-dev-new/drivers/net/wireless/b43/dma.c
===
--- wireless-dev-new.orig/drivers/net/wireless/b43/dma.c2007-08-12 
16:38:51.0 +0200
+++ wireless-dev-new/drivers/net/wireless/b43/dma.c 2007-08-13 
16:01:07.0 +0200
@@ -1276,12 +1276,15 @@ void b43_dma_handle_txstatus(struct b43_
if (status->acked) {
meta->txstat.flags |= IEEE80211_TX_STATUS_ACK;
} else {
-   if (!
-   (meta->txstat.control.
-flags & IEEE80211_TXCTL_NO_ACK))
+   if (!(meta->txstat.control.flags
+ & IEEE80211_TXCTL_NO_ACK))
meta->txstat.excessive_retries = 1;
}
-   meta->txstat.retry_count = status->frame_count - 1;
+   if (status->frame_count == 0) {
+   /* The frame was not transmitted at all. */
+   meta->txstat.retry_count = 0;
+   } else
+   meta->txstat.retry_count = status->frame_count 
- 1;
ieee80211_tx_status_irqsafe(dev->wl->hw, meta->skb,
&(meta->txstat));
/* skb is freed by ieee80211_tx_status_irqsafe() */
Index: wireless-dev-new/drivers/net/wireless/b43/pio.c
===
--- wireless-dev-new.orig/drivers/net/wireless/b43/pio.c2007-08-12 
16:38:52.0 +0200
+++ wireless-dev-new/drivers/net/wireless/b43/pio.c 2007-08-13 
16:02:24.0 +0200
@@ -469,7 +469,11 @@ void b43_pio_handle_txstatus(struct b43_
if (!(packet->txstat.control.flags & IEEE80211_TXCTL_NO_ACK))
packet->txstat.excessive_retries = 1;
}
-   packet->txstat.retry_count = status->frame_count - 1;
+   if (status->frame_count == 0) {
+   /* The frame was not transmitted at all. */
+   packet->txstat.retry_count = 0;
+   } else
+   packet->txstat.retry_count = status->frame_count - 1;
ieee80211_tx_status_irqsafe(dev->wl->hw, packet->skb,
&(packet->txstat));
packet->skb = NULL;

-- 

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[patch 6/9] b43: debugfs tx_status, Fix endless loop inside of spinlock

2007-08-14 Thread Michael Buesch
This fixes an endless loop inside of a spinlock.
This triggers if the tx_status file is read before a packet
has been transmitted.

Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: wireless-dev-new/drivers/net/wireless/b43/debugfs.c
===
--- wireless-dev-new.orig/drivers/net/wireless/b43/debugfs.c2007-08-12 
16:38:51.0 +0200
+++ wireless-dev-new/drivers/net/wireless/b43/debugfs.c 2007-08-13 
15:48:06.0 +0200
@@ -173,6 +173,10 @@ static ssize_t txstat_read_file(struct f
i = log->end + 1;
idx = 0;
while (1) {
+   if (log->end < 0) {
+   fappend("Nothing transmitted, yet\n");
+   break;
+   }
if (i == B43_NR_LOGGED_TXSTATUS)
i = 0;
stat = &(log->log[i]);

-- 

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[patch 5/9] b43: Suppress sending of probe responses from firmware

2007-08-14 Thread Michael Buesch
The MLME takes care of this.
In future we probably want to change the MLME to support this
hardware feature.

Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: wireless-dev-new/drivers/net/wireless/b43/main.c
===
--- wireless-dev-new.orig/drivers/net/wireless/b43/main.c   2007-08-12 
22:03:12.0 +0200
+++ wireless-dev-new/drivers/net/wireless/b43/main.c2007-08-13 
14:24:30.0 +0200
@@ -3328,6 +3328,12 @@ static int b43_wireless_core_init(struct
b43_shm_write16(dev, B43_SHM_SHARED, B43_SHM_SH_SFFBLIM, 3);
b43_shm_write16(dev, B43_SHM_SHARED, B43_SHM_SH_LFFBLIM, 2);
 
+   /* Disable sending probe responses from firmware.
+* Setting the MaxTime to one usec will always trigger
+* a timeout, so we never send any probe resp.
+* A timeout of zero is infinite. */
+   b43_shm_write16(dev, B43_SHM_SHARED, B43_SHM_SH_PRMAXTIME, 1);
+
b43_rate_memory_init(dev);
 
/* Minimum Contention Window */

-- 

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[patch 0/9] New patch series for merge

2007-08-14 Thread Michael Buesch
Hi John,

This patch series catches wireless-dev up to my
current wireless-development patchset.

Please merge this into wireless-dev.


-- 

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [patch 0/7] SSB: New patch series for merge

2007-08-14 Thread Michael Buesch
On Tuesday 14 August 2007 19:34:08 Larry Finger wrote:
> Michael Buesch wrote:
> > Hi John,
> > 
> > This patch series catches SSB up to my
> > current wireless-development patchset.
> > 
> > Please merge this into wireless-dev ssb branch.
> 
> I had a problem with #7. My copy of John's tree still has EXPERIMENTAL for 
> ssb. Yours does not.

Are you sure you have latest wireless-dev? It has
been rebased again.

-- 
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [patch 0/7] SSB: New patch series for merge

2007-08-14 Thread Larry Finger
Michael Buesch wrote:
> Hi John,
> 
> This patch series catches SSB up to my
> current wireless-development patchset.
> 
> Please merge this into wireless-dev ssb branch.

I had a problem with #7. My copy of John's tree still has EXPERIMENTAL for ssb. 
Yours does not.

The differences are:

--- ../ssb_patch7_from_MB   2007-08-14 12:27:51.0 -0500
+++ patches/ssb_patch7_works  2007-08-14 12:26:31.0 -0500
@@ -15,7 +15,7 @@
  +
   config SSB
 tristate "Sonics Silicon Backplane support"
--  depends on HAS_IOMEM
+-  depends on EXPERIMENTAL && HAS_IOMEM
  +  depends on SSB_POSSIBLE
 help
  -Support for the Sonics Silicon Backplane bus
@@ -50,12 +50,12 @@

  +config SSB_PCMCIAHOST_POSSIBLE
  +  bool
-+  depends on SSB && PCMCIA && EXPERIMENTAL
++  depends on SSB && PCMCIA
  +  default y
  +
   config SSB_PCMCIAHOST
-   bool "Support for SSB on PCMCIA-bus host (EXPERIMENTAL)"
--  depends on SSB && PCMCIA && EXPERIMENTAL
+   bool "Support for SSB on PCMCIA-bus host"
+-  depends on SSB && PCMCIA
  +  depends on SSB_PCMCIAHOST_POSSIBLE
 help
   Support for a Sonics Silicon Backplane on top
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[patch 7/7] ssb: Add kconfig SELECT workaround

2007-08-14 Thread Michael Buesch
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: ssb-merge-new/drivers/ssb/Kconfig
===
--- ssb-merge-new.orig/drivers/ssb/Kconfig  2007-08-14 17:05:12.0 
+0200
+++ ssb-merge-new/drivers/ssb/Kconfig   2007-08-14 17:22:13.0 +0200
@@ -1,18 +1,33 @@
 menu "Sonics Silicon Backplane"
 
+config SSB_POSSIBLE
+   bool
+   depends on HAS_IOMEM
+   default y
+
 config SSB
tristate "Sonics Silicon Backplane support"
-   depends on HAS_IOMEM
+   depends on SSB_POSSIBLE
help
- Support for the Sonics Silicon Backplane bus
+ Support for the Sonics Silicon Backplane bus.
+ You only need to enable this option, if you are
+ configuring a kernel for an embedded system with
+ this bus.
+ It will be auto-selected if needed in other
+ environments.
 
- The module will be called ssb
+ The module will be called ssb.
 
- If unsure, say M
+ If unsure, say N.
+
+config SSB_PCIHOST_POSSIBLE
+   bool
+   depends on SSB && PCI
+   default y
 
 config SSB_PCIHOST
bool "Support for SSB on PCI-bus host"
-   depends on SSB && PCI
+   depends on SSB_PCIHOST_POSSIBLE
default y
help
  Support for a Sonics Silicon Backplane on top
@@ -20,9 +35,14 @@ config SSB_PCIHOST
 
  If unsure, say Y
 
+config SSB_PCMCIAHOST_POSSIBLE
+   bool
+   depends on SSB && PCMCIA && EXPERIMENTAL
+   default y
+
 config SSB_PCMCIAHOST
bool "Support for SSB on PCMCIA-bus host (EXPERIMENTAL)"
-   depends on SSB && PCMCIA && EXPERIMENTAL
+   depends on SSB_PCMCIAHOST_POSSIBLE
help
  Support for a Sonics Silicon Backplane on top
  of a PCMCIA device.
@@ -31,7 +51,7 @@ config SSB_PCMCIAHOST
 
 config SSB_SILENT
bool "No SSB kernel messages"
-   depends on SSB
+   depends on SSB && EMBEDDED
help
  This option turns off all Sonics Silicon Backplane printks.
  Note that you won't be able to identify problems, once
@@ -55,9 +75,14 @@ config SSB_SERIAL
depends on SSB
# ChipCommon and ExtIf serial support routines.
 
+config SSB_DRIVER_PCICORE_POSSIBLE
+   bool
+   depends on SSB_PCIHOST
+   default y
+
 config SSB_DRIVER_PCICORE
bool "SSB PCI core driver"
-   depends on SSB && SSB_PCIHOST
+   depends on SSB_DRIVER_PCICORE_POSSIBLE
help
  Driver for the Sonics Silicon Backplane attached
  Broadcom PCI core.

-- 

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[patch 6/7] ssb: Add debugging for buspower

2007-08-14 Thread Michael Buesch
Always make sure buspower is applied, when accessing the PCI MMIO space.
Otherwise this can result in crashes.

Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: ssb-merge-new/drivers/ssb/main.c
===
--- ssb-merge-new.orig/drivers/ssb/main.c   2007-08-13 17:33:23.0 
+0200
+++ ssb-merge-new/drivers/ssb/main.c2007-08-13 17:33:34.0 +0200
@@ -131,6 +131,9 @@ static void ssb_bus_suspend(struct ssb_b
 #ifdef CONFIG_SSB_DRIVER_PCICORE
bus->pcicore.setup_done = 0;
 #endif
+#ifdef CONFIG_SSB_DEBUG
+   bus->powered_up = 0;
+#endif
 }
 
 static int ssb_device_suspend(struct device *dev, pm_message_t state)
@@ -486,9 +489,14 @@ static int ssb_attach_queued_buses(void)
 * is too early in boot for embedded systems
 * (no udelay() available). So do it here in attach stage.
 */
+   err = ssb_bus_powerup(bus, 0);
+   if (err)
+   goto error;
ssb_pcicore_init(&bus->pcicore);
+   ssb_bus_may_powerdown(bus);
 
err = ssb_devices_register(bus);
+error:
if (err) {
drop_them_all = 1;
list_del(&bus->list);
@@ -586,11 +594,17 @@ static int ssb_bus_register(struct ssb_b
goto err_pci_exit;
 
/* Initialize basic system devices (if available) */
+   err = ssb_bus_powerup(bus, 0);
+   if (err)
+   goto err_pcmcia_exit;
ssb_chipcommon_init(&bus->chipco);
ssb_mipscore_init(&bus->mipscore);
err = ssb_fetch_invariants(bus, get_invariants);
-   if (err)
+   if (err) {
+   ssb_bus_may_powerdown(bus);
goto err_pcmcia_exit;
+   }
+   ssb_bus_may_powerdown(bus);
 
/* Queue it for attach.
 * See the comment at the ssb_is_early_boot definition. */
@@ -1012,24 +1026,27 @@ EXPORT_SYMBOL(ssb_dma_set_mask);
 int ssb_bus_may_powerdown(struct ssb_bus *bus)
 {
struct ssb_chipcommon *cc;
-   int err;
+   int err = 0;
 
/* On buses where more than one core may be working
 * at a time, we must not powerdown stuff if there are
 * still cores that may want to run. */
if (bus->bustype == SSB_BUSTYPE_SSB)
-   return 0;
+   goto out;
 
cc = &bus->chipco;
ssb_chipco_set_clockmode(cc, SSB_CLKMODE_SLOW);
err = ssb_pci_xtal(bus, SSB_GPIO_XTAL | SSB_GPIO_PLL, 0);
if (err)
goto error;
-
-   return 0;
+out:
+#ifdef CONFIG_SSB_DEBUG
+   bus->powered_up = 0;
+#endif
+   return err;
 error:
ssb_printk(KERN_ERR PFX "Bus powerdown failed\n");
-   return err;
+   goto out;
 }
 EXPORT_SYMBOL(ssb_bus_may_powerdown);
 
@@ -1046,6 +1063,9 @@ int ssb_bus_powerup(struct ssb_bus *bus,
mode = dynamic_pctl ? SSB_CLKMODE_DYNAMIC : SSB_CLKMODE_FAST;
ssb_chipco_set_clockmode(cc, mode);
 
+#ifdef CONFIG_SSB_DEBUG
+   bus->powered_up = 1;
+#endif
return 0;
 error:
ssb_printk(KERN_ERR PFX "Bus powerup failed\n");
Index: ssb-merge-new/drivers/ssb/pci.c
===
--- ssb-merge-new.orig/drivers/ssb/pci.c2007-08-11 20:25:54.0 
+0200
+++ ssb-merge-new/drivers/ssb/pci.c 2007-08-13 17:33:34.0 +0200
@@ -499,10 +499,34 @@ out:
return err;
 }
 
+#ifdef CONFIG_SSB_DEBUG
+static int ssb_pci_assert_buspower(struct ssb_bus *bus)
+{
+   if (likely(bus->powered_up))
+   return 0;
+
+   printk(KERN_ERR PFX "FATAL ERROR: Bus powered down "
+  "while accessing PCI MMIO space\n");
+   if (bus->power_warn_count <= 10) {
+   bus->power_warn_count++;
+   dump_stack();
+   }
+
+   return -ENODEV;
+}
+#else /* DEBUG */
+static inline int ssb_pci_assert_buspower(struct ssb_bus *bus)
+{
+   return 0;
+}
+#endif /* DEBUG */
+
 static u16 ssb_pci_read16(struct ssb_device *dev, u16 offset)
 {
struct ssb_bus *bus = dev->bus;
 
+   if (unlikely(ssb_pci_assert_buspower(bus)))
+   return 0x;
if (unlikely(bus->mapped_device != dev)) {
if (unlikely(ssb_pci_switch_core(bus, dev)))
return 0x;
@@ -514,6 +538,8 @@ static u32 ssb_pci_read32(struct ssb_dev
 {
struct ssb_bus *bus = dev->bus;
 
+   if (unlikely(ssb_pci_assert_buspower(bus)))
+   return 0x;
if (unlikely(bus->mapped_device != dev)) {
if (unlikely(ssb_pci_switch_core(bus, dev)))
return 0x;
@@ -525,6 +551,8 @@ static void ssb_pci_write16(struct ssb_d
 {
struct ssb_bus *bus = dev->bus;
 
+   if (unlikely(ssb_pci_assert_buspower(bus)))
+   return;
if (unlikely(bus->mapped_device != dev)) {

[patch 2/7] ssb: include modalias in uevent for core

2007-08-14 Thread Michael Buesch
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: ssb-merge-new/drivers/ssb/main.c
===
--- ssb-merge-new.orig/drivers/ssb/main.c   2007-08-11 01:57:31.0 
+0200
+++ ssb-merge-new/drivers/ssb/main.c2007-08-11 20:26:57.0 +0200
@@ -317,6 +317,24 @@ static int ssb_bus_match(struct device *
return 0;
 }
 
+static int ssb_device_uevent(struct device *dev, char **envp, int num_envp,
+char *buffer, int buffer_size)
+{
+   struct ssb_device *ssb_dev = dev_to_ssb_dev(dev);
+   int ret, i = 0, length = 0;
+
+   if (!dev)
+   return -ENODEV;
+
+   ret = add_uevent_var(envp, num_envp, &i,
+buffer, buffer_size, &length,
+"MODALIAS=ssb:v%.4xid%.4xrev%.2x",
+ssb_dev->id.vendor, ssb_dev->id.coreid,
+ssb_dev->id.revision);
+   envp[i] = NULL;
+   return ret;
+}
+
 static struct bus_type ssb_bustype = {
.name   = "ssb",
.match  = ssb_bus_match,
@@ -325,6 +343,7 @@ static struct bus_type ssb_bustype = {
.shutdown   = ssb_device_shutdown,
.suspend= ssb_device_suspend,
.resume = ssb_device_resume,
+   .uevent = ssb_device_uevent,
 };
 
 static void ssb_buses_lock(void)

-- 

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[patch 4/7] ssb: Fix a warning in PCI core driver

2007-08-14 Thread Michael Buesch
From: Aurelien Jarno <[EMAIL PROTECTED]>

The patch below fixes a warning spotted a few days ago by Andrew Morton
while releasing 2.6.23-rc2-mm1.

Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: ssb-merge-new/include/linux/ssb/ssb_regs.h
===
--- ssb-merge-new.orig/include/linux/ssb/ssb_regs.h 2007-08-11 
01:57:44.0 +0200
+++ ssb-merge-new/include/linux/ssb/ssb_regs.h  2007-08-13 14:17:30.0 
+0200
@@ -5,24 +5,24 @@
 /* SiliconBackplane Address Map.
  * All regions may not exist on all chips.
  */
-#define SSB_SDRAM_BASE 0x  /* Physical SDRAM */
-#define SSB_PCI_MEM0x0800  /* Host Mode sb2pcitranslation0 
(64 MB) */
-#define SSB_PCI_CFG0x0c00  /* Host Mode sb2pcitranslation1 
(64 MB) */
-#defineSSB_SDRAM_SWAPPED   0x1000  /* Byteswapped Physical 
SDRAM */
-#define SSB_ENUM_BASE  0x1800  /* Enumeration space base */
-#defineSSB_ENUM_LIMIT  0x1801  /* Enumeration space 
limit */
-
-#defineSSB_FLASH2  0x1c00  /* Flash Region 2 
(region 1 shadowed here) */
-#defineSSB_FLASH2_SZ   0x0200  /* Size of Flash Region 
2 */
-
-#defineSSB_EXTIF_BASE  0x1f00  /* External Interface 
region base address */
-#defineSSB_FLASH1  0x1fc0  /* Flash Region 1 */
-#defineSSB_FLASH1_SZ   0x0040  /* Size of Flash Region 
1 */
-
-#define SSB_PCI_DMA0x4000  /* Client Mode 
sb2pcitranslation2 (1 GB) */
-#define SSB_PCI_DMA_SZ 0x4000  /* Client Mode 
sb2pcitranslation2 size in bytes */
-#define SSB_PCIE_DMA_L32   0x  /* PCIE Client Mode 
sb2pcitranslation2 (2 ZettaBytes), low 32 bits */
-#define SSB_PCIE_DMA_H32   0x8000  /* PCIE Client Mode 
sb2pcitranslation2 (2 ZettaBytes), high 32 bits */
+#define SSB_SDRAM_BASE 0xU /* Physical SDRAM */
+#define SSB_PCI_MEM0x0800U /* Host Mode sb2pcitranslation0 
(64 MB) */
+#define SSB_PCI_CFG0x0c00U /* Host Mode sb2pcitranslation1 
(64 MB) */
+#defineSSB_SDRAM_SWAPPED   0x1000U /* Byteswapped Physical 
SDRAM */
+#define SSB_ENUM_BASE  0x1800U /* Enumeration space base */
+#defineSSB_ENUM_LIMIT  0x1801U /* Enumeration space 
limit */
+
+#defineSSB_FLASH2  0x1c00U /* Flash Region 2 
(region 1 shadowed here) */
+#defineSSB_FLASH2_SZ   0x0200U /* Size of Flash Region 
2 */
+
+#defineSSB_EXTIF_BASE  0x1f00U /* External Interface 
region base address */
+#defineSSB_FLASH1  0x1fc0U /* Flash Region 1 */
+#defineSSB_FLASH1_SZ   0x0040U /* Size of Flash Region 
1 */
+
+#define SSB_PCI_DMA0x4000U /* Client Mode 
sb2pcitranslation2 (1 GB) */
+#define SSB_PCI_DMA_SZ 0x4000U /* Client Mode 
sb2pcitranslation2 size in bytes */
+#define SSB_PCIE_DMA_L32   0xU /* PCIE Client Mode 
sb2pcitranslation2 (2 ZettaBytes), low 32 bits */
+#define SSB_PCIE_DMA_H32   0x8000U /* PCIE Client Mode 
sb2pcitranslation2 (2 ZettaBytes), high 32 bits */
 #defineSSB_EUART   (SSB_EXTIF_BASE + 0x0080)
 #defineSSB_LED (SSB_EXTIF_BASE + 0x0090)
 

-- 

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[patch 0/7] SSB: New patch series for merge

2007-08-14 Thread Michael Buesch
Hi John,

This patch series catches SSB up to my
current wireless-development patchset.

Please merge this into wireless-dev ssb branch.


-- 

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[patch 5/7] ssb: Add Broadcom 43xx PCI to SSB bridge

2007-08-14 Thread Michael Buesch
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: ssb-merge-new/drivers/ssb/Makefile
===
--- ssb-merge-new.orig/drivers/ssb/Makefile 2007-08-13 17:35:33.0 
+0200
+++ ssb-merge-new/drivers/ssb/Makefile  2007-08-13 17:35:49.0 +0200
@@ -11,4 +11,8 @@ ssb-$(CONFIG_SSB_DRIVER_MIPS) += driver
 ssb-$(CONFIG_SSB_DRIVER_EXTIF) += driver_extif.o
 ssb-$(CONFIG_SSB_DRIVER_PCICORE)   += driver_pcicore.o
 
+# b43 pci-ssb-bridge driver
+# Not strictly a part of SSB, but kept here for convenience
+ssb-$(CONFIG_SSB_PCIHOST)  += b43_pci_bridge.o
+
 obj-$(CONFIG_SSB)  += ssb.o
Index: ssb-merge-new/drivers/ssb/b43_pci_bridge.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ ssb-merge-new/drivers/ssb/b43_pci_bridge.c  2007-08-13 17:42:24.0 
+0200
@@ -0,0 +1,45 @@
+/*
+ * Broadcom 43xx PCI-SSB bridge module
+ *
+ * This technically is a seperate PCI driver module, but
+ * because of its small size we include it in the SSB core
+ * instead of creating a standalone module.
+ *
+ * Copyright 2007  Michael Buesch <[EMAIL PROTECTED]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#include 
+#include 
+
+
+static const struct pci_device_id b43_pci_bridge_tbl[] = {
+   { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4307) },
+   { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4311) },
+   { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4312) },
+   { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4318) },
+   { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4319) },
+   { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4320) },
+   { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4321) },
+   { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
+   { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4325) },
+   { 0, },
+};
+MODULE_DEVICE_TABLE(pci, b43_pci_bridge_tbl);
+
+static struct pci_driver b43_pci_bridge_driver = {
+   .name = "b43-pci-bridge",
+   .id_table = b43_pci_bridge_tbl,
+};
+
+
+int __init b43_pci_ssb_bridge_init(void)
+{
+   return ssb_pcihost_register(&b43_pci_bridge_driver);
+}
+
+void __exit b43_pci_ssb_bridge_exit(void)
+{
+   ssb_pcihost_unregister(&b43_pci_bridge_driver);
+}
Index: ssb-merge-new/drivers/ssb/main.c
===
--- ssb-merge-new.orig/drivers/ssb/main.c   2007-08-13 17:35:49.0 
+0200
+++ ssb-merge-new/drivers/ssb/main.c2007-08-13 17:40:14.0 +0200
@@ -1121,12 +1121,21 @@ static int __init ssb_modinit(void)
if (err)
bus_unregister(&ssb_bustype);
 
+   err = b43_pci_ssb_bridge_init();
+   if (err) {
+   ssb_printk(KERN_ERR "Broadcom 43xx PCI-SSB-bridge "
+  "initialization failed");
+   /* don't fail SSB init because of this */
+   err = 0;
+   }
+
return err;
 }
 subsys_initcall(ssb_modinit);
 
 static void __exit ssb_modexit(void)
 {
+   b43_pci_ssb_bridge_exit();
bus_unregister(&ssb_bustype);
 }
 module_exit(ssb_modexit)
Index: ssb-merge-new/drivers/ssb/ssb_private.h
===
--- ssb-merge-new.orig/drivers/ssb/ssb_private.h2007-08-13 
17:35:33.0 +0200
+++ ssb-merge-new/drivers/ssb/ssb_private.h 2007-08-13 17:35:49.0 
+0200
@@ -119,4 +119,18 @@ extern int ssb_devices_freeze(struct ssb
 extern int ssb_devices_thaw(struct ssb_bus *bus);
 extern struct ssb_bus *ssb_pci_dev_to_bus(struct pci_dev *pdev);
 
+/* b43_pci_bridge.c */
+#ifdef CONFIG_SSB_PCIHOST
+extern int __init b43_pci_ssb_bridge_init(void);
+extern void __exit b43_pci_ssb_bridge_exit(void);
+#else /* CONFIG_SSB_PCIHOST */
+static inline int b43_pci_ssb_bridge_init(void)
+{
+   return 0;
+}
+static inline void b43_pci_ssb_bridge_exit(void)
+{
+}
+#endif /* CONFIG_SSB_PCIHOST */
+
 #endif /* LINUX_SSB_PRIVATE_H_ */

-- 

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[patch 3/7] ssb: Add GPIO support to Chip Common and PCI core drivers

2007-08-14 Thread Michael Buesch
From: Aurelien Jarno <[EMAIL PROTECTED]>

The patch below adds a functions to Chip Common and PCI core drivers to
access the GPIO lines.

Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: ssb-merge-new/drivers/ssb/driver_chipcommon.c
===
--- ssb-merge-new.orig/drivers/ssb/driver_chipcommon.c  2007-08-11 
20:25:54.0 +0200
+++ ssb-merge-new/drivers/ssb/driver_chipcommon.c   2007-08-13 
14:16:39.0 +0200
@@ -39,6 +39,14 @@ static inline void chipco_write32(struct
ssb_write32(cc->dev, offset, value);
 }
 
+static inline void chipco_write32_masked(struct ssb_chipcommon *cc, u16 offset,
+u32 mask, u32 value)
+{
+   value &= mask;
+   value |= chipco_read32(cc, offset) & ~mask;
+   chipco_write32(cc, offset, value);
+}
+
 void ssb_chipco_set_clockmode(struct ssb_chipcommon *cc,
  enum ssb_clkmode mode)
 {
@@ -344,6 +352,21 @@ ssb_chipco_watchdog_timer_set(struct ssb
chipco_write32(cc, SSB_CHIPCO_WATCHDOG, ticks);
 }
 
+u32 ssb_chipco_gpio_in(struct ssb_chipcommon *cc, u32 mask)
+{
+   return chipco_read32(cc, SSB_CHIPCO_GPIOIN) & mask;
+}
+
+void ssb_chipco_gpio_out(struct ssb_chipcommon *cc, u32 mask, u32 value)
+{
+   return chipco_write32_masked(cc, SSB_CHIPCO_GPIOOUT, mask, value);
+}
+
+void ssb_chipco_gpio_outen(struct ssb_chipcommon *cc, u32 mask, u32 value)
+{
+   return chipco_write32_masked(cc, SSB_CHIPCO_GPIOOUTEN, mask, value);
+}
+
 #ifdef CONFIG_SSB_SERIAL
 int ssb_chipco_serial_init(struct ssb_chipcommon *cc,
   struct ssb_serial_port *ports)
Index: ssb-merge-new/drivers/ssb/driver_extif.c
===
--- ssb-merge-new.orig/drivers/ssb/driver_extif.c   2007-08-11 
01:57:31.0 +0200
+++ ssb-merge-new/drivers/ssb/driver_extif.c2007-08-13 14:16:39.0 
+0200
@@ -27,6 +27,14 @@ static inline void extif_write32(struct 
ssb_write32(extif->dev, offset, value);
 }
 
+static inline void extif_write32_masked(struct ssb_extif *extif, u16 offset,
+   u32 mask, u32 value)
+{
+   value &= mask;
+   value |= extif_read32(extif, offset) & ~mask;
+   extif_write32(extif, offset, value);
+}
+
 #ifdef CONFIG_SSB_SERIAL
 static bool serial_exists(u8 *regs)
 {
@@ -102,3 +110,20 @@ void ssb_extif_get_clockcontrol(struct s
*m = extif_read32(extif, SSB_EXTIF_CLOCK_SB);
 }
 
+u32 ssb_extif_gpio_in(struct ssb_extif *extif, u32 mask)
+{
+   return extif_read32(extif, SSB_EXTIF_GPIO_IN) & mask;
+}
+
+void ssb_extif_gpio_out(struct ssb_extif *extif, u32 mask, u32 value)
+{
+   return extif_write32_masked(extif, SSB_EXTIF_GPIO_OUT(0),
+  mask, value);
+}
+
+void ssb_extif_gpio_outen(struct ssb_extif *extif, u32 mask, u32 value)
+{
+   return extif_write32_masked(extif, SSB_EXTIF_GPIO_OUTEN(0),
+  mask, value);
+}
+
Index: ssb-merge-new/include/linux/ssb/ssb_driver_chipcommon.h
===
--- ssb-merge-new.orig/include/linux/ssb/ssb_driver_chipcommon.h
2007-08-11 01:57:44.0 +0200
+++ ssb-merge-new/include/linux/ssb/ssb_driver_chipcommon.h 2007-08-13 
14:16:39.0 +0200
@@ -382,6 +382,12 @@ extern void ssb_chipco_set_clockmode(str
 extern void ssb_chipco_watchdog_timer_set(struct ssb_chipcommon *cc,
  u32 ticks);
 
+u32 ssb_chipco_gpio_in(struct ssb_chipcommon *cc, u32 mask);
+
+void ssb_chipco_gpio_out(struct ssb_chipcommon *cc, u32 mask, u32 value);
+
+void ssb_chipco_gpio_outen(struct ssb_chipcommon *cc, u32 mask, u32 value);
+
 #ifdef CONFIG_SSB_SERIAL
 extern int ssb_chipco_serial_init(struct ssb_chipcommon *cc,
  struct ssb_serial_port *ports);
Index: ssb-merge-new/include/linux/ssb/ssb_driver_extif.h
===
--- ssb-merge-new.orig/include/linux/ssb/ssb_driver_extif.h 2007-08-11 
01:57:44.0 +0200
+++ ssb-merge-new/include/linux/ssb/ssb_driver_extif.h  2007-08-13 
14:16:39.0 +0200
@@ -171,6 +171,12 @@ extern void ssb_extif_get_clockcontrol(s
 extern void ssb_extif_timing_init(struct ssb_extif *extif,
  unsigned long ns);
 
+u32 ssb_extif_gpio_in(struct ssb_extif *extif, u32 mask);
+
+void ssb_extif_gpio_out(struct ssb_extif *extif, u32 mask, u32 value);
+
+void ssb_extif_gpio_outen(struct ssb_extif *extif, u32 mask, u32 value);
+
 #ifdef CONFIG_SSB_SERIAL
 extern int ssb_extif_serial_init(struct ssb_extif *extif,
 struct ssb_serial_port *ports);

-- 

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de

[patch 1/7] ssb: generate modaliases for modules

2007-08-14 Thread Michael Buesch
This makes the build system magic generate the appropriate
modaliases for MODULE_DEVICE_TABLE(ssb, ...)

Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: ssb-merge-new/include/linux/mod_devicetable.h
===
--- ssb-merge-new.orig/include/linux/mod_devicetable.h  2007-08-11 
01:57:43.0 +0200
+++ ssb-merge-new/include/linux/mod_devicetable.h   2007-08-11 
20:26:09.0 +0200
@@ -339,4 +339,19 @@ struct parisc_device_id {
 #define PA_HVERSION_ANY_ID 0x
 #define PA_SVERSION_ANY_ID 0x
 
+/* SSB core, see drivers/ssb/ */
+struct ssb_device_id {
+   __u16   vendor;
+   __u16   coreid;
+   __u8revision;
+};
+#define SSB_DEVICE(_vendor, _coreid, _revision)  \
+   { .vendor = _vendor, .coreid = _coreid, .revision = _revision, }
+#define SSB_DEVTABLE_END  \
+   { 0, },
+
+#define SSB_ANY_VENDOR 0x
+#define SSB_ANY_ID 0x
+#define SSB_ANY_REV0xFF
+
 #endif /* LINUX_MOD_DEVICETABLE_H */
Index: ssb-merge-new/include/linux/ssb/ssb.h
===
--- ssb-merge-new.orig/include/linux/ssb/ssb.h  2007-08-11 01:57:44.0 
+0200
+++ ssb-merge-new/include/linux/ssb/ssb.h   2007-08-11 20:26:09.0 
+0200
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -153,20 +154,6 @@ struct ssb_bus_ops {
 /* Vendor-ID values */
 #define SSB_VENDOR_BROADCOM0x4243
 
-struct ssb_device_id {
-   u16 vendor;
-   u16 coreid;
-   u8 revision;
-};
-#define SSB_DEVICE(_vendor, _coreid, _revision)  \
-   { .vendor = _vendor, .coreid = _coreid, .revision = _revision, }
-#define SSB_DEVTABLE_END  \
-   { 0, },
-
-#define SSB_ANY_VENDOR 0x
-#define SSB_ANY_ID 0x
-#define SSB_ANY_REV0xFF
-
 /* Some kernel subsystems poke with dev->drvdata, so we must use the
  * following ugly workaround to get from struct device to struct ssb_device */
 struct __ssb_dev_wrapper {
Index: ssb-merge-new/scripts/mod/file2alias.c
===
--- ssb-merge-new.orig/scripts/mod/file2alias.c 2007-08-11 01:57:48.0 
+0200
+++ ssb-merge-new/scripts/mod/file2alias.c  2007-08-11 20:26:09.0 
+0200
@@ -484,6 +484,21 @@ static int do_parisc_entry(const char *f
return 1;
 }
 
+/* Looks like: ssb:vNidNrevN. */
+static int do_ssb_entry(const char *filename,
+   struct ssb_device_id *id, char *alias)
+{
+   id->vendor = TO_NATIVE(id->vendor);
+   id->coreid = TO_NATIVE(id->coreid);
+   id->revision = TO_NATIVE(id->revision);
+
+   strcpy(alias, "ssb:");
+   ADD(alias, "v", id->vendor != SSB_ANY_VENDOR, id->vendor);
+   ADD(alias, "id", id->coreid != SSB_ANY_ID, id->coreid);
+   ADD(alias, "rev", id->revision != SSB_ANY_REV, id->revision);
+   return 1;
+}
+
 /* Ignore any prefix, eg. v850 prepends _ */
 static inline int sym_is(const char *symbol, const char *name)
 {
@@ -599,6 +614,10 @@ void handle_moddevtable(struct module *m
do_table(symval, sym->st_size,
 sizeof(struct parisc_device_id), "parisc",
 do_parisc_entry, mod);
+   else if (sym_is(symname, "__mod_ssb_device_table"))
+   do_table(symval, sym->st_size,
+sizeof(struct ssb_device_id), "ssb",
+do_ssb_entry, mod);
 }
 
 /* Now add out buffered information to the generated C source */

-- 

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: 4311 works with fedora 7 but only at 1mb/s

2007-08-14 Thread Larry Finger
John H. wrote:
> I spoke too soon.  I just tried it again and it seemed stuck on 1 mb/s
> and there was an obvious difference in network speed.  hmm.

If you don't want the auto speed adjustment, or are unhappy with it, you can 
change the rate setting 
with the 'iwconfig eth1 rate Y' command. As your system seems not to auto-scale 
very well, I would 
try values for Y of 11M, 18M, 24M, 36M, 48M, and 54M (in that order). For each 
speed, try a ping 
flood against your AP (ping -f 192.168.1.1, or whatever address is shown as the 
gateway in a 'route 
-n' command). As long as you don't see a lot of dots from the flood, it is safe 
to try the next 
higher speed. Once you get a failure, you might want to back off one extra 
speed for safety.

Have you tried changing the AP's channel, if possible? You might find less 
interference with a 
different setting. Does your location have any other 2.4 GHz devices like 
portable telephones or 
baby monitors, etc. They could interfere.

Larry

___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: debian etch wireless

2007-08-14 Thread Larry Finger
Cavan Mejias wrote:
> I have a dell inspiron 1501 with debian etch installed. I installed 
> bcm43xx-fwcutter and downloaded the firmware. however my wireless light 
> does not come on at boot. lspci 
> shows:  05:00.0 Network controller: 
> Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card (rev 01)
> 08:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX 
> (rev 02) .
> everything else seems to function. Iwconfig doesn't list any wireless 
> extentions at all.

Please send the output of 'dmesg | grep bcm'.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


debian etch wireless

2007-08-14 Thread Cavan Mejias
I have a dell inspiron 1501 with debian etch installed. I installed
bcm43xx-fwcutter and downloaded the firmware. however my wireless light does
not come on at boot. lspci shows:  05:
00.0 Network controller: Broadcom Corporation Dell Wireless 1390 WLAN
Mini-PCI Card (rev 01)
08:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev
02) .
everything else seems to function. Iwconfig doesn't list any wireless
extentions at all.

Any ideas. Thanks
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: 4311 not working

2007-08-14 Thread Larry Finger
Jason Wood wrote:
> 
> I'm going to continue my efforts to update the bios to solve this 
> problem, but getting a working Windows installation is harder than it 
> should be.  BartPE requires Windows to install (thankfully I had a spare 
> PC), and fails in wine.  After finally creating a disk, the default 
> settings for video don't seem to work with my laptop.
> 
> I do appreciate your help Larry, and I thank you for all your hard work 
> on this driver.

What is your Nvidea graphics adapter? Perhaps I can make a CD for you. I have a 
Geforce Go 6150 on 
my HP dv2125nr. I keep XP on my machine just in case of this sort of issue. 
Once I get the thing 
built, I'll post the iso file on my FTP site, and let you know where to find it.

Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Port to a common pci bridge

2007-08-14 Thread Michael Buesch
On Monday 13 August 2007 18:00:12 Johannes Berg wrote:
> You forgot this:
> 
> --- wireless-dev.orig/drivers/ssb/b43_pci_bridge.c2007-08-13 
> 17:57:32.205589257 +0200
> +++ wireless-dev/drivers/ssb/b43_pci_bridge.c 2007-08-13 17:57:49.915589257 
> +0200
> @@ -27,6 +27,8 @@ static const struct pci_device_id b43_pc
>   { 0, },
>  };
>  
> +MODULE_DEVICE_TABLE(pci, b43_pci_bridge_tbl);
> +
>  static struct pci_driver b43_pci_bridge_driver = {
>   .name = "b43-pci-bridge",
>   .id_table = b43_pci_bridge_tbl,
> 
> 
> 
> 

I already updated my patches.

-- 
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [RFC] Proposed changes to fwcutter

2007-08-14 Thread Johannes Berg
On Mon, 2007-08-13 at 22:26 +0200, Martin Langer wrote:

> > a0g0bsinitvalsN ?
> > a0g0initvalsN   ?
> > a0g1bsinitvalsN ?
> > a0g1initvalsN   ?
> > b0g0bsinitvalsN ?
> > b0g0initvalsN   ?
> 
> Hmm, it sounds as cryptic as before. But I'm not living in the re 
> world ;)

Heh. Well, it's not too bad, I think I explained the scheme some time
ago. In any case, it makes it far easier for us to explain this area.

johannes


signature.asc
Description: This is a digitally signed message part
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Port to a common pci bridge

2007-08-14 Thread Johannes Berg
You forgot this:

--- wireless-dev.orig/drivers/ssb/b43_pci_bridge.c  2007-08-13 
17:57:32.205589257 +0200
+++ wireless-dev/drivers/ssb/b43_pci_bridge.c   2007-08-13 17:57:49.915589257 
+0200
@@ -27,6 +27,8 @@ static const struct pci_device_id b43_pc
{ 0, },
 };
 
+MODULE_DEVICE_TABLE(pci, b43_pci_bridge_tbl);
+
 static struct pci_driver b43_pci_bridge_driver = {
.name = "b43-pci-bridge",
.id_table = b43_pci_bridge_tbl,


___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev