Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Sun, 2007-08-05 at 12:18 +0200, Michael Buesch wrote: Well, it's not that easy. Current code just doesn't make any sense. I do not understand how hardware power control works exactly, so I can't write some detailed message or something. That's probably a chicken and egg problem ;) OK, the existing code complains that one number is larger than another. You don't want to hide that message, but when I ask you to explain, you say that the code makes no sense to you. Somehow, it doesn't sound right. Nobody knows the code better than you. I think communication is essential for development. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 4/5] bcm43xx-mac80211: Fix regression in interrupt handling
From: Larry Finger [EMAIL PROTECTED] Since commit 85a83d26697dd2203ac4e5f33022951f2c3e6e33, bcm43xx-mac80211: Rewrite and simplify handling of the initialization status, some PCI adapters have problems due to interrupts happening before the device status reaches BCM43xx_STARTED. This patch delays the initial interrupt enable until after the device status is set. Signed-off-by: Larry Finger [EMAIL PROTECTED] Signed-off-by: Michael Buesch [EMAIL PROTECTED] Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c === --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c 2007-08-03 23:37:34.0 +0200 +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c 2007-08-06 14:04:45.0 +0200 @@ -3014,13 +3014,13 @@ static int bcm43xx_wireless_core_start(s dev-dev-irq); goto out; } - bcm43xx_interrupt_enable(dev, dev-irq_savedstate); bcm43xx_mac_enable(dev); bcm43xx_periodic_tasks_setup(dev); ieee80211_start_queues(dev-wl-hw); bcm43xx_set_status(dev, BCM43xx_STAT_STARTED); + bcm43xx_interrupt_enable(dev, dev-irq_savedstate); bcmdbg(dev-wl, Wireless interface started\n); out: return err; -- ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 3/5] bcm43xx-mac80211: Set antenna gains if not in sprom
From: Larry Finger [EMAIL PROTECTED] In the sprom for bcm43xx devices, any unprogrammed values are set to all ones. In the case of antenna gains, the specs indicate that a gain of 2 dBm should be set if no value is stored. This patch implements that provision. Signed-off-by: Larry Finger [EMAIL PROTECTED] Signed-off-by: Michael Buesch [EMAIL PROTECTED] Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c === --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c 2007-08-02 16:47:33.0 +0200 +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c 2007-08-03 23:37:34.0 +0200 @@ -3805,6 +3805,12 @@ static void bcm43xx_sprom_fixup(struct s bus-boardinfo.rev 0x40) bus-sprom.r1.boardflags_lo |= BCM43xx_BFL_PACTRL; + /* Handle case when gain is not set in sprom */ + if (bus-sprom.r1.antenna_gain_a == 0xFF) + bus-sprom.r1.antenna_gain_a = 2; + if (bus-sprom.r1.antenna_gain_bg == 0xFF) + bus-sprom.r1.antenna_gain_bg = 2; + /* Convert Antennagain values to Q5.2 */ bus-sprom.r1.antenna_gain_a = 2; bus-sprom.r1.antenna_gain_bg = 2; -- ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 1/5] bcm43xx-mac80211: Provide information to allow transmission rate decreases
From: Larry Finger [EMAIL PROTECTED]
Fixed-by: Michael Buesch [EMAIL PROTECTED]
In bcm43xx-mac80211, the mechanism for decreasing the transmit rate cannot
be triggered. This may be shown by walking away from the AP with a laptop.
At some distance, communications will be lost and never recovered because
the rate decreasing mechanism of rc80211_simple needs to see excessive_retries
set in the ieee80211_tx_status struct. With this patch, the transmit rate
will decrease until communications restart.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
2007-08-02 23:31:33.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
2007-08-02 23:39:35.0 +0200
@@ -1309,8 +1309,12 @@ void bcm43xx_dma_handle_txstatus(struct
* status of the transmission.
* Some fields of txstat are already filled in dma_tx().
*/
- if (status-acked)
+ if (status-acked) {
meta-txstat.flags |= IEEE80211_TX_STATUS_ACK;
+ } else {
+ if (!(meta-txstat.control.flags
IEEE80211_TXCTL_NO_ACK))
+ meta-txstat.excessive_retries = 1;
+ }
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/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_pio.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_pio.c
2007-08-02 16:47:33.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_pio.c
2007-08-02 23:39:56.0 +0200
@@ -487,8 +487,12 @@ void bcm43xx_pio_handle_txstatus(struct
queue-tx_devq_packets--;
queue-tx_devq_used -= (packet-skb-len + sizeof(struct
bcm43xx_txhdr_fw4));
- if (status-acked)
+ if (status-acked) {
packet-txstat.flags |= IEEE80211_TX_STATUS_ACK;
+ } else {
+ if (!(packet-txstat.control.flags IEEE80211_TXCTL_NO_ACK))
+ packet-txstat.excessive_retries = 1;
+ }
packet-txstat.retry_count = status-frame_count - 1;
ieee80211_tx_status_irqsafe(dev-wl-hw, packet-skb,
(packet-txstat));
--
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[patch 2/5] Always use dev_kfree_skb_any()
This will always work.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
2007-08-03 23:35:31.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
2007-08-03 23:35:33.0 +0200
@@ -441,14 +441,10 @@ void sync_descbuffer_for_device(struct b
static inline
void free_descriptor_buffer(struct bcm43xx_dmaring *ring,
- struct bcm43xx_dmadesc_meta *meta,
- int irq_context)
+ struct bcm43xx_dmadesc_meta *meta)
{
if (meta-skb) {
- if (irq_context)
- dev_kfree_skb_irq(meta-skb);
- else
- dev_kfree_skb(meta-skb);
+ dev_kfree_skb_any(meta-skb);
meta-skb = NULL;
}
}
@@ -777,7 +773,7 @@ static void free_all_descbuffers(struct
unmap_descbuffer(ring, meta-dmaaddr,
ring-rx_buffersize, 0);
}
- free_descriptor_buffer(ring, meta, 0);
+ free_descriptor_buffer(ring, meta);
}
}
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_pio.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_pio.c
2007-08-03 23:35:31.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_pio.c
2007-08-03 23:35:33.0 +0200
@@ -208,17 +208,12 @@ static void pio_tx_write_fragment(struct
tx_complete(queue, skb);
}
-static void free_txpacket(struct bcm43xx_pio_txpacket *packet,
- int irq_context)
+static void free_txpacket(struct bcm43xx_pio_txpacket *packet)
{
struct bcm43xx_pioqueue *queue = packet-queue;
- if (packet-skb) {
- if (irq_context)
- dev_kfree_skb_irq(packet-skb);
- else
- dev_kfree_skb(packet-skb);
- }
+ if (packet-skb)
+ dev_kfree_skb_any(packet-skb);
list_move(packet-list, queue-txfree);
queue-nr_txfree++;
}
@@ -234,7 +229,7 @@ static int pio_tx_packet(struct bcm43xx_
bcmwarn(queue-dev-wl, PIO queue too small.
Dropping packet.\n);
/* Drop it silently (return success) */
- free_txpacket(packet, 1);
+ free_txpacket(packet);
return 0;
}
assert(queue-tx_devq_packets = BCM43xx_PIO_MAXTXDEVQPACKETS);
@@ -371,9 +366,9 @@ static void cancel_transfers(struct bcm4
tasklet_disable(queue-txtask);
list_for_each_entry_safe(packet, tmp_packet, queue-txrunning, list)
- free_txpacket(packet, 0);
+ free_txpacket(packet);
list_for_each_entry_safe(packet, tmp_packet, queue-txqueue, list)
- free_txpacket(packet, 0);
+ free_txpacket(packet);
}
static void bcm43xx_destroy_pioqueue(struct bcm43xx_pioqueue *queue)
@@ -498,7 +493,7 @@ void bcm43xx_pio_handle_txstatus(struct
(packet-txstat));
packet-skb = NULL;
- free_txpacket(packet, 1);
+ free_txpacket(packet);
/* If there are packets on the txqueue, poke the tasklet
* to transmit them.
*/
--
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Monday 06 August 2007, Pavel Roskin wrote: On Sun, 2007-08-05 at 12:18 +0200, Michael Buesch wrote: Well, it's not that easy. Current code just doesn't make any sense. I do not understand how hardware power control works exactly, so I can't write some detailed message or something. That's probably a chicken and egg problem ;) OK, the existing code complains that one number is larger than another. You don't want to hide that message, but when I ask you to explain, you say that the code makes no sense to you. So? Somehow, it doesn't sound right. Nobody knows the code better than you. I think communication is essential for development. I know that this is broken (So we don't hide the bug by removing the message), but I don't know how to fix it. Is that such an unusual condition? I simply don't understand how the hardware works. Sure, we can simply hide the bug by changing the code so that it doesn't complain anymore. That's not the issue here. The problem is, that I don't know how to fix this _correctly_. So, that said, I'm not sure which lack of communication you are talking about. I do _not_ know how that stuff works. So, if you want to try understanding it, read the code and specs and try to make sense out of it. I am working on this stuff. I have limited time and I'm not Merlin the magician. So I have to try understanding this stuff. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Mon, 2007-08-06 at 08:42 -0400, Joseph Jezak wrote: The problem is that the reverse engineering team (myself and Johannes) don't understand the code in the original driver well enough. The power control code is certainly the most confusing and incomplete part of our specs. While I'd love to spend the time figuring it out, I just can't spend that time right now. Well, this reminds me The Mad Hatter's Tea Party with me being Alice :) Anyway, good luck with the driver work! -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
Pavel Roskin wrote: On Sun, 2007-08-05 at 12:18 +0200, Michael Buesch wrote: Well, it's not that easy. Current code just doesn't make any sense. I do not understand how hardware power control works exactly, so I can't write some detailed message or something. That's probably a chicken and egg problem ;) OK, the existing code complains that one number is larger than another. You don't want to hide that message, but when I ask you to explain, you say that the code makes no sense to you. Somehow, it doesn't sound right. Nobody knows the code better than you. I think communication is essential for development. Pavel, The problem is that the reverse engineering team (myself and Johannes) don't understand the code in the original driver well enough. The power control code is certainly the most confusing and incomplete part of our specs. While I'd love to spend the time figuring it out, I just can't spend that time right now. -Joe ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but?Ethernet appears broken
On Monday 06 August 2007, John W. Linville wrote: On Sat, Aug 04, 2007 at 06:47:29PM +0200, Michael Buesch wrote: On Saturday 04 August 2007, Larry Finger wrote: Pavel Roskin wrote: On Fri, 2007-08-03 at 20:46 -0500, Larry Finger wrote: The size of LO array message is not fatal. I'll really appreciate if it's removed or at least the stack dump is suppressed. We know already that it's a problem, so why scare users more than they need to? We know where it happens, why show the stack? I don't think we want to make users ignore stack traces in the kernel logs, because we may not hear about unknown problems. IMHO there are better places for TODO notes than innocent users' kernel logs. I agree completely; however, I've had my hands slapped in the past for removing that kind of message. As a result, I leave them alone. Well, there are good reasons for not removing this. The resons include that this message is only shown for the debug build. So if you want it to shut up, don't compile a debug build. Is there a real need for the call to dump_stack on err? Isn't the printk (bcmdbg) good enough? Well, without a stacktrace you don't know who caused the error. We can remove that. But I still don't know what we gain from removing useful debug messages. If you don't care about bcm43xx bugs, simply disable bcm43xx debugging. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but?Ethernet appears broken
Michael Buesch wrote:
Well, without a stacktrace you don't know who caused the error.
We can remove that. But I still don't know what we gain from
removing useful debug messages. If you don't care about bcm43xx bugs, simply
disable bcm43xx debugging.
Michael, I agree with you in general, but in this case we know that the line
bbatt.att = 11 in
bcm43xx_phy_init_pctl leads to this error message. Why don't we change it to
'bbatt.att = 8' to
eliminate this particular error message? That way the debugging info can stay
in without polluting
everyone's log.
Larry
The patch is:
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
@@ -725,7 +725,7 @@ static void bcm43xx_phy_init_pctl(struct
memcpy(old_bbatt, phy-bbatt, sizeof(old_bbatt));
old_tx_control = phy-tx_control;
- bbatt.att = 11;
+ bbatt.att = 8;
if (phy-radio_rev == 8) {
rfatt.att = 15;
rfatt.with_padmix = 1;
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but?Ethernet appears broken
On Monday 06 August 2007, Larry Finger wrote: Michael Buesch wrote: Well, without a stacktrace you don't know who caused the error. We can remove that. But I still don't know what we gain from removing useful debug messages. If you don't care about bcm43xx bugs, simply disable bcm43xx debugging. Michael, I agree with you in general, but in this case we know that the line bbatt.att = 11 in bcm43xx_phy_init_pctl leads to this error message. Why don't we change it to 'bbatt.att = 8' to eliminate this particular error message? That way the debugging info can stay in without polluting everyone's log. Because that would simply be plain wrong. The specs says we have to write 11. So we write 11 and not something else to workaround bugs in other parts of the code. I don't feel comfortable with introducing bugs to hide other bugs. Someone must reverse engineer all that stuff again. But currently we have nobody with enough time to do this. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 IPv6 problems
On Fri, Aug 03, 2007 at 01:02:12AM -0700, Michael Wu wrote:
This doesn't seem quite right. I think ieee80211_rx_h_data is a safer place
for this check (inside the IEEE80211_FCTL_FROMDS case), and allows various
statistics to be updated. ieee80211_rx_h_sta_process is another function that
might work though that would probably involve more code to add all the right
checks.
The patch below seems to work for me w/ an otherwise stock F-7 kernel
w/ iwl3945. Thoughts?
From: John W. Linville [EMAIL PROTECTED]
[PATCH] mac80211: filter locally-originated multicast frames
In STA mode, the AP will echo our traffic. This includes multicast
traffice.
Receiving these frames confuses some protocols and applications,
notably IPv6 Duplicate Address Detection.
Signed-off-by: John W. Linville [EMAIL PROTECTED]
---
net/mac80211/ieee80211.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index a42e70e..0097b0a 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -3030,9 +3030,10 @@ ieee80211_rx_h_data(struct ieee80211_txrx_data *rx)
memcpy(dst, hdr-addr1, ETH_ALEN);
memcpy(src, hdr-addr3, ETH_ALEN);
- if (sdata-type != IEEE80211_IF_TYPE_STA) {
+ if (sdata-type != IEEE80211_IF_TYPE_STA ||
+ (is_multicast_ether_addr(dst)
+!compare_ether_addr(src, dev-dev_addr)))
return TXRX_DROP;
- }
break;
case 0:
/* DA SA BSSID */
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On 8/6/07, Pavel Roskin [EMAIL PROTECTED] wrote: On Sun, 2007-08-05 at 12:18 +0200, Michael Buesch wrote: Well, it's not that easy. Current code just doesn't make any sense. I do not understand how hardware power control works exactly, so I can't write some detailed message or something. That's probably a chicken and egg problem ;) OK, the existing code complains that one number is larger than another. You don't want to hide that message, but when I ask you to explain, you say that the code makes no sense to you. I will attempt an explanation of the issue, since I've been trying to wrap my own head around it lately. It boils down to a contradiction in the specs. For a G phy, the power control is set by 2 attenuation values. The chip wants the values themselves, and also the results of looking up these values in the LO table (which we build at device init and periodically refresh). The specs tell us how to build the LO table by looping over a list of values and measuring hardware parameters for each (http://bcm-v4.sipsolutions.net/802.11/LO/GPHY/BuildingTheTable). The list of values is supplied (http://bcm-v4.sipsolutions.net/802.11/LO/Tables). We make the LO lookup table large enough to hold all these values, but no larger than that (since anything else should not be initialized according to specs). Then the specs tell us to initialize the power control by setting the TX power variables to a known state and measuring power output (http://bcm-v4.sipsolutions.net/802.11/PHY/G/Power_Control). Here is the problem: One of the TX power values the spec tells us to use for this is larger than the max value used when building the LO lookup table. To set the TX power, we need to index into the LO table with these values. The spec is telling us to lookup an invalid index in the LO table. Currently, the driver deals with this by catching invalid LO table indexes and returning the value at the zero index. But this cannot possibly be the right thing to do; it merely avoids an oops in the driver. When high-level code tells low-level code to do something stupid, printing a warning seems appropriate (even if a stack trace is not needed any more). -- Will Dyson ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[RFC] bcm43xx-mac80211: Add TX power set file to debugfs
For testing purposes, this patch adds a file named power_level to the
debugfs for bcm43xx-mac80211. If this file is read, it returns the current
setting for the Desired power level. Writing a number between 5 and 18
will set that value as the new value for the desired power setting.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
@@ -151,6 +151,74 @@ out_unlock_bb:
return res;
}
+static ssize_t power_read_file(struct file *file, char __user *userbuf,
+size_t count, loff_t *ppos)
+{
+ struct bcm43xx_wldev *dev = file-private_data;
+ const size_t len = ARRAY_SIZE(big_buffer);
+ char *buf = big_buffer;
+ size_t pos = 0;
+ ssize_t res;
+ unsigned long flags;
+
+ mutex_lock(big_buffer_mutex);
+ mutex_lock(dev-wl-mutex);
+ spin_lock_irqsave(dev-wl-irq_lock, flags);
+ if (bcm43xx_status(dev) BCM43xx_STAT_STARTED) {
+ fappend(Board not initialized.\n);
+ goto out;
+ }
+ fappend(%d dBm\n,dev-phy.power_level);
+
+out:
+ spin_unlock_irqrestore(dev-wl-irq_lock, flags);
+ mutex_unlock(dev-wl-mutex);
+ res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
+ mutex_unlock(big_buffer_mutex);
+
+ return res;
+}
+
+static ssize_t power_write_file(struct file *file, const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct bcm43xx_wldev *dev = file-private_data;
+ char *buf = big_buffer;
+ ssize_t buf_size;
+ ssize_t res;
+ unsigned long flags;
+ int power;
+
+ mutex_lock(big_buffer_mutex);
+ buf_size = min(count, ARRAY_SIZE(big_buffer) - 1);
+ if (copy_from_user(buf, user_buf, buf_size)) {
+ res = -EFAULT;
+ goto out_unlock_bb;
+ }
+ mutex_lock(dev-wl-mutex);
+ spin_lock_irqsave(dev-wl-irq_lock, flags);
+ if (bcm43xx_status(dev) BCM43xx_STAT_STARTED) {
+ bcmerr(dev-wl, debugfs: Board not initialized.\n);
+ res = -EFAULT;
+ goto out_unlock;
+ }
+ if ((sscanf(buf, %d, power) != 1) || (power 18 || power 5)) {
+ bcmerr(dev-wl, debugfs: Invalid values for power level\n);
+ res = -EINVAL;
+ goto out_unlock;
+ }
+ dev-phy.power_level = power;
+ res = buf_size;
+
+out_unlock:
+ spin_unlock_irqrestore(dev-wl-irq_lock, flags);
+ mutex_unlock(dev-wl-mutex);
+out_unlock_bb:
+ mutex_unlock(big_buffer_mutex);
+
+ return res;
+}
+
static ssize_t txstat_read_file(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
{
@@ -405,6 +473,12 @@ static struct file_operations restart_fo
.open = open_file_generic,
};
+static struct file_operations power_fops = {
+ .read = power_read_file,
+ .write = power_write_file,
+ .open = open_file_generic,
+};
+
int bcm43xx_debug(struct bcm43xx_wldev *dev, enum bcm43xx_dyndbg feature)
{
@@ -495,6 +569,11 @@ void bcm43xx_debugfs_add_device(struct b
if (IS_ERR(e-dentry_restart))
e-dentry_restart = NULL;
+ e-dentry_power = debugfs_create_file(power_level, 0600, e-subdir,
+dev, power_fops);
+ if (IS_ERR(e-dentry_power))
+ e-dentry_power = NULL;
+
bcm43xx_add_dynamic_debug(dev);
}
@@ -512,6 +591,7 @@ void bcm43xx_debugfs_remove_device(struc
debugfs_remove(e-dentry_txstat);
debugfs_remove(e-dentry_restart);
debugfs_remove(e-dentry_txpower_g);
+ debugfs_remove(e-dentry_power);
debugfs_remove(e-subdir);
kfree(e-txstatlog.log);
kfree(e);
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.h
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.h
@@ -35,6 +35,7 @@ struct bcm43xx_dfsentry {
struct dentry *dentry_txstat;
struct dentry *dentry_txpower_g;
struct dentry *dentry_restart;
+ struct dentry *dentry_power;
struct bcm43xx_wldev *dev;
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
@@ -2762,12 +2762,11 @@ static int bcm43xx_dev_config(struct iee
}
/*
Re: [RFC] bcm43xx-mac80211: Add TX power set file to debugfs
On Monday 06 August 2007 22:22:14 Larry Finger wrote:
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
@@ -2762,12 +2762,11 @@ static int bcm43xx_dev_config(struct iee
}
/* Adjust the desired TX power level. */
- if (conf-power_level != 0) {
- if (conf-power_level != phy-power_level) {
- phy-power_level = conf-power_level;
- bcm43xx_phy_xmitpower(dev);
- }
- }
+ if (conf-power_level != 0 phy-power_level == 0) {
+ phy-power_level = conf-power_level;
+ } else
+ phy-power_level = 10;
+ bcm43xx_phy_xmitpower(dev);
No, what's that? I disagree with that.
This breaks power adjustment.
/* Hide/Show the SSID (AP mode only). */
if (conf-flags IEEE80211_CONF_SSID_HIDDEN) {
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] bcm43xx-mac80211: Add TX power set file to debugfs
Michael Buesch wrote:
On Monday 06 August 2007 22:22:14 Larry Finger wrote:
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
@@ -2762,12 +2762,11 @@ static int bcm43xx_dev_config(struct iee
}
/* Adjust the desired TX power level. */
-if (conf-power_level != 0) {
-if (conf-power_level != phy-power_level) {
-phy-power_level = conf-power_level;
-bcm43xx_phy_xmitpower(dev);
-}
-}
+if (conf-power_level != 0 phy-power_level == 0) {
+phy-power_level = conf-power_level;
+} else
+phy-power_level = 10;
+bcm43xx_phy_xmitpower(dev);
No, what's that? I disagree with that.
This breaks power adjustment.
I just discovered that it fails. When I find the problem, I'll resubmit. Is the
debugfs part right?
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Port of bcm43xx from softmac to mac80211 is available for testing
On Sunday 05 August 2007 23:11:33 you wrote: Richard Jonsson wrote: Isn't Desired TX power supposed to adapt so that higher bitrates are possible, with Bit Rate going lower if that is not enough to keep a good connection? It should, but this feature is not yet implemented. I have some test code to do this, but it is not ready. When it is, I'll send you a trial patch. Check if your system has a file names /sys/kernel/debug/bcm43xx/phyX/power_level. If it does, you can write new values for the Desired power into it. Values up to 18 are allowed. I see, and thank you for the tip. I thought power_level was read-only. 11M mode is unusable at all distances, 12M works fine. This probably breaks rate scaling for me. Yes, it certainly would. My 4311 shows a little dip at 11 Mbs, but not as big as yours. Is your AP using b/g mode, or just g mode? What is the make and model of the AP? It's a netgear wgt634u, most recent stable firmware, configured for B/G. rmmod bcm43xx when kde is running hangs rmmod and prevents a clean shutdown. I tried to find which program causes this while using bcm4301 driver, but so far no luck. System shuts down fine if I don't try to rmmod first. rmmod works fine from runlevel 3 aside from this message when inserting module again: net eth1: device_rename: sysfs_create_symlink failed (-17) On my system, I routinely unload the module using 'modprobe -r bcm43xx'. Sometimes, it happens 20 or 30 times between reboots. These are always at runlevel 5. Only once or twice has it not completed. Are you using NetworkManager or using the traditional ifup/ifdown methods? Networkmanager+knetworkmanager. killing these before rmmod doesn't help. Nitpicking: When changing bitrate manually it will not show up with iwconfig before any traffic has occured. This is a mac80211 problem. My original version of the patch that implemented the set rate function loaded the new rate so that it would show up immediately, but that part was nixed. Complain on [EMAIL PROTECTED] Maybe I will. It's not that big of an issue, but still confusing for those unknowing. Sometimes iwconfig link quality shows values in the whole 0-255 range. Do the Signal and Noise levels show -256 dBm at the same time? If so, mac80211 has not received any data. Sometimes signal fluctuates at the same time, noise is pretty much always around -70dBm. I can't recall I've seen it show -256 for this driver. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] bcm43xx-mac80211: Add TX power set file to debugfs
On Monday 06 August 2007 22:36:49 Larry Finger wrote:
Michael Buesch wrote:
On Monday 06 August 2007 22:22:14 Larry Finger wrote:
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
@@ -2762,12 +2762,11 @@ static int bcm43xx_dev_config(struct iee
}
/* Adjust the desired TX power level. */
- if (conf-power_level != 0) {
- if (conf-power_level != phy-power_level) {
- phy-power_level = conf-power_level;
- bcm43xx_phy_xmitpower(dev);
- }
- }
+ if (conf-power_level != 0 phy-power_level == 0) {
+ phy-power_level = conf-power_level;
+ } else
+ phy-power_level = 10;
+ bcm43xx_phy_xmitpower(dev);
No, what's that? I disagree with that.
This breaks power adjustment.
I just discovered that it fails. When I find the problem, I'll resubmit. Is
the debugfs part right?
I think so.
Although, (I think you know that), it does not immediately
reconfigure the power, but waits for the next pwork with enough
tssi information.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[RFC V2] bcm43xx-mac80211: Add TX power set file to debugfs
For testing purposes, this patch adds a file named power_level to the
debugfs for bcm43xx-mac80211. If this file is read, it returns the current
setting for the Desired power level. Writing a number between 5 and 18
will set that value as the new value for the desired power setting.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Michael,
The error before is fixed in this version.
Larry
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
@@ -151,6 +151,74 @@ out_unlock_bb:
return res;
}
+static ssize_t power_read_file(struct file *file, char __user *userbuf,
+size_t count, loff_t *ppos)
+{
+ struct bcm43xx_wldev *dev = file-private_data;
+ const size_t len = ARRAY_SIZE(big_buffer);
+ char *buf = big_buffer;
+ size_t pos = 0;
+ ssize_t res;
+ unsigned long flags;
+
+ mutex_lock(big_buffer_mutex);
+ mutex_lock(dev-wl-mutex);
+ spin_lock_irqsave(dev-wl-irq_lock, flags);
+ if (bcm43xx_status(dev) BCM43xx_STAT_STARTED) {
+ fappend(Board not initialized.\n);
+ goto out;
+ }
+ fappend(%d dBm\n,dev-phy.power_level);
+
+out:
+ spin_unlock_irqrestore(dev-wl-irq_lock, flags);
+ mutex_unlock(dev-wl-mutex);
+ res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
+ mutex_unlock(big_buffer_mutex);
+
+ return res;
+}
+
+static ssize_t power_write_file(struct file *file, const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct bcm43xx_wldev *dev = file-private_data;
+ char *buf = big_buffer;
+ ssize_t buf_size;
+ ssize_t res;
+ unsigned long flags;
+ int power;
+
+ mutex_lock(big_buffer_mutex);
+ buf_size = min(count, ARRAY_SIZE(big_buffer) - 1);
+ if (copy_from_user(buf, user_buf, buf_size)) {
+ res = -EFAULT;
+ goto out_unlock_bb;
+ }
+ mutex_lock(dev-wl-mutex);
+ spin_lock_irqsave(dev-wl-irq_lock, flags);
+ if (bcm43xx_status(dev) BCM43xx_STAT_STARTED) {
+ bcmerr(dev-wl, debugfs: Board not initialized.\n);
+ res = -EFAULT;
+ goto out_unlock;
+ }
+ if ((sscanf(buf, %d, power) != 1) || (power 18 || power 5)) {
+ bcmerr(dev-wl, debugfs: Invalid values for power level\n);
+ res = -EINVAL;
+ goto out_unlock;
+ }
+ dev-phy.power_level = power;
+ res = buf_size;
+
+out_unlock:
+ spin_unlock_irqrestore(dev-wl-irq_lock, flags);
+ mutex_unlock(dev-wl-mutex);
+out_unlock_bb:
+ mutex_unlock(big_buffer_mutex);
+
+ return res;
+}
+
static ssize_t txstat_read_file(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
{
@@ -405,6 +473,12 @@ static struct file_operations restart_fo
.open = open_file_generic,
};
+static struct file_operations power_fops = {
+ .read = power_read_file,
+ .write = power_write_file,
+ .open = open_file_generic,
+};
+
int bcm43xx_debug(struct bcm43xx_wldev *dev, enum bcm43xx_dyndbg feature)
{
@@ -495,6 +569,11 @@ void bcm43xx_debugfs_add_device(struct b
if (IS_ERR(e-dentry_restart))
e-dentry_restart = NULL;
+ e-dentry_power = debugfs_create_file(power_level, 0600, e-subdir,
+dev, power_fops);
+ if (IS_ERR(e-dentry_power))
+ e-dentry_power = NULL;
+
bcm43xx_add_dynamic_debug(dev);
}
@@ -512,6 +591,7 @@ void bcm43xx_debugfs_remove_device(struc
debugfs_remove(e-dentry_txstat);
debugfs_remove(e-dentry_restart);
debugfs_remove(e-dentry_txpower_g);
+ debugfs_remove(e-dentry_power);
debugfs_remove(e-subdir);
kfree(e-txstatlog.log);
kfree(e);
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.h
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.h
@@ -35,6 +35,7 @@ struct bcm43xx_dfsentry {
struct dentry *dentry_txstat;
struct dentry *dentry_txpower_g;
struct dentry *dentry_restart;
+ struct dentry *dentry_power;
struct bcm43xx_wldev *dev;
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
@@ -2763,7 +2763,8 @@ static
Re: [RFC V2] bcm43xx-mac80211: Add TX power set file to debugfs
Michael Buesch wrote: No, why do you poke with this at all. This completely breaks power adjustment from mac80211. Simply don't touch bcm43xx_dev_config :) The problem is that mac80211 never seems to do any power adjustment. The funny 0x1b value for power level that I wondered about earlier is coming from a value of 27 dBm that is set in net/mac80211/regdomain.c, and conf-power_level doesn't get any information from anywhere else that I see. Do you know how to get mac80211 to change what it is sending to us? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] bcm43xx-mac80211: Hack to turn automatic pctl off
On Monday 06 August 2007 23:29:04 Larry Finger wrote:
Michael,
I sent the wrong message under this subject before.
This hack disabled hardware power control. With this installed and the
desired power set to 10 dBm using the previous patch, I get much, much
better performance from bcm43xx-mac80211 on my BCM4311. I have not yet
tested it on the BCM4306 or the BCM4318.
The new iperf readings for transmit/receive with the computer about 2 m
from the AP are as follows:
Bit Rate xmit/receive (Mbs)
1M1.11/8.70
2M1.44/11.0
5.5M 4.15/13.3
6M4.76/17.4
9M6.55/18.2
11M 6.54/14.3
18M 10.7/18.5
24M 12.8/19.5
36M 16.1/19.7
48M 18.0/19.5
54M 18.6/19.0
These numbers are comparable with what I'm getting with the PHY port from
softmac. I don't understand the dip in received rate at 11M, but it is real.
On Richard Jonsson's 4311, he isn't able to measure the transfer rate at
11M.
With these settings, the rate adjustment proces bumps the rate to 54M
automatically.
Larry
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
@@ -471,6 +471,7 @@ void bcm43xx_phy_early_init(struct bcm43
struct bcm43xx_phy *phy = dev-phy;
struct bcm43xx_txpower_lo_control *lo = phy-lo_control;
+ phy-hw_pctl_off = 1;
default_baseband_attenuation(dev, phy-bbatt);
default_radio_attenuation(dev, phy-rfatt);
phy-tx_control = (default_tx_control(dev) 4);
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.h
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.h
@@ -219,8 +219,9 @@ void bcm43xx_gphy_dc_lt_init(struct bcm4
/* Returns the boolean whether the board has HardwarePowerControl */
#define has_hardware_pctl(phy) \
+ (!((phy)-hw_pctl_off)\
(((phy)-type == BCM43xx_PHYTYPE_A (phy)-rev = 5) || \
- ((phy)-type == BCM43xx_PHYTYPE_G (phy)-rev = 6))
+ ((phy)-type == BCM43xx_PHYTYPE_G (phy)-rev = 6)))
/* Returns the boolean whether TX Magnification is enabled. */
#define has_tx_magnification(phy) \
(((phy)-rev = 2)\
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
@@ -534,6 +534,7 @@ struct bcm43xx_phy {
struct bcm43xx_bbatt bbatt;
struct bcm43xx_rfatt rfatt;
u8 tx_control; /* BCM43xx_TXCTL_XXX */
+ bool hw_pctl_off;
#ifdef CONFIG_BCM43XX_MAC80211_DEBUG
bool manual_txpower_control; /* Manual TX-power control enabled? */
#endif
---
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
I am currently doing a patch for this.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] bcm43xx-mac80211: Hack to turn automatic pctl off
On Monday 06 August 2007 23:35:48 Michael Buesch wrote:
On Monday 06 August 2007 23:29:04 Larry Finger wrote:
Michael,
I sent the wrong message under this subject before.
This hack disabled hardware power control. With this installed and the
desired power set to 10 dBm using the previous patch, I get much, much
better performance from bcm43xx-mac80211 on my BCM4311. I have not yet
tested it on the BCM4306 or the BCM4318.
The new iperf readings for transmit/receive with the computer about 2 m
from the AP are as follows:
Bit Ratexmit/receive (Mbs)
1M 1.11/8.70
2M 1.44/11.0
5.5M4.15/13.3
6M 4.76/17.4
9M 6.55/18.2
11M 6.54/14.3
18M 10.7/18.5
24M 12.8/19.5
36M 16.1/19.7
48M 18.0/19.5
54M 18.6/19.0
These numbers are comparable with what I'm getting with the PHY port from
softmac. I don't understand the dip in received rate at 11M, but it is real.
On Richard Jonsson's 4311, he isn't able to measure the transfer rate at
11M.
With these settings, the rate adjustment proces bumps the rate to 54M
automatically.
Larry
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
@@ -471,6 +471,7 @@ void bcm43xx_phy_early_init(struct bcm43
struct bcm43xx_phy *phy = dev-phy;
struct bcm43xx_txpower_lo_control *lo = phy-lo_control;
+ phy-hw_pctl_off = 1;
default_baseband_attenuation(dev, phy-bbatt);
default_radio_attenuation(dev, phy-rfatt);
phy-tx_control = (default_tx_control(dev) 4);
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.h
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.h
@@ -219,8 +219,9 @@ void bcm43xx_gphy_dc_lt_init(struct bcm4
/* Returns the boolean whether the board has HardwarePowerControl */
#define has_hardware_pctl(phy) \
+ (!((phy)-hw_pctl_off)\
(((phy)-type == BCM43xx_PHYTYPE_A (phy)-rev = 5) || \
-((phy)-type == BCM43xx_PHYTYPE_G (phy)-rev = 6))
+((phy)-type == BCM43xx_PHYTYPE_G (phy)-rev = 6)))
/* Returns the boolean whether TX Magnification is enabled. */
#define has_tx_magnification(phy) \
(((phy)-rev = 2)\
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
@@ -534,6 +534,7 @@ struct bcm43xx_phy {
struct bcm43xx_bbatt bbatt;
struct bcm43xx_rfatt rfatt;
u8 tx_control; /* BCM43xx_TXCTL_XXX */
+ bool hw_pctl_off;
#ifdef CONFIG_BCM43XX_MAC80211_DEBUG
bool manual_txpower_control; /* Manual TX-power control enabled? */
#endif
---
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
I am currently doing a patch for this.
That's it
http://bu3sch.de/patches/wireless-dev/20070806-1186437386/patches/bcm43xx-mac80211-hwpctl-optional.patch
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
