sensitive to DMA latencies? Take a look at
the pm_qos code in ipw2100.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
.
The latency is the amount of time it takes to get out of deep C states
and into C0. That's a function of the processor design rather than the
frequency.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https
. If it turns out that it is
required, efforts should be made to limit it to the code regions that
absolutely require this behaviour.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https
.
The dell-laptop driver is worth a go - it provides support for
controlling the Dell-specific rfkill interface. It may (or may not) help
here.
--
Matthew Garrett | mj...@srcf.ucam.org
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https
name of this rfkill switch */
--
Matthew Garrett | [EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
On Wed, Dec 10, 2008 at 04:48:29PM +0100, Michael Buesch wrote:
On Wednesday 10 December 2008 16:09:35 Matthew Garrett wrote:
I've reworked the rfkill code in b43. This ought to be more consistent
...
I'm fine with this, as long as you take over the responsibility for the whole
b43
. The way we currently handle that (and,
I think, the only way we *can* handle that) is to provide two separate
rfkill interfaces - one tied to the wireless device, one tied to the
platform device.
--
Matthew Garrett | [EMAIL PROTECTED]
___
Bcm43xx-dev
hw switch device.
Right. That's prety close to the current situation.
If we need to tie them together in software it gets more complicated
though.
I think we can avoid that, thankfully.
--
Matthew Garrett | [EMAIL PROTECTED]
___
Bcm43xx-dev
switch */
--
Matthew Garrett | [EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
timer_list poll_timer;
+ /* Workqueue for the RFKILL polling */
+ struct work_struct poll_queue;
/* Did initialization succeed? Used for freeing. */
bool registered;
/* The unique name of this rfkill switch */
--
Matthew Garrett | [EMAIL PROTECTED
being generated by rfkill-input trying to change the state after
it's already been changed. The general intent is correct.
--
Matthew Garrett | [EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman
a day. I have already run 3 new kernels
today.
We don't. Shipped firmware is provided in /lib/firmware/`uname -r` in
order to ensure that we can keep it in sync with module updates.
User-installed firmware can stay in /lib/firmware.
--
Matthew Garrett | [EMAIL PROTECTED
and shipped. Things should be rectified in the next
upload.
--
Matthew Garrett | [EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
appear at the top level.
--
Matthew Garrett | [EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
, unfortunately...
--
Matthew Garrett | [EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
the closed broadcom
driver. I've got three sets of these messages at 120 second intervals,
and then another after 240 seconds, which makes me think it's linked to
some sort of periodic event. Any further debug info I can provide?
--
Matthew Garrett | [EMAIL PROTECTED
On Sat, Feb 10, 2007 at 06:00:59PM +0100, Michael Buesch wrote:
Strange. THat shouldn't happen.
Can you post complete dmesg?
Attached.
--
Matthew Garrett | [EMAIL PROTECTED]
Feb 10 16:06:02 vaio kernel: [0.00] Linux version 2.6.20-7-generic
([EMAIL PROTECTED]) (gcc version 4.1.2
as an entirely separate branch of the device tree, which doesn't
seem quite right.
--
Matthew Garrett | [EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
also drive the old cards?
--
Matthew Garrett | [EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
the interface vanishing and reappearing. Larry, I guess you just
mean this as a test patch?
--
Matthew Garrett | [EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
On Sat, Jan 27, 2007 at 06:36:07PM +0100, Michael Buesch wrote:
On Saturday 27 January 2007 00:25, Matthew Garrett wrote:
But while you use .v3, most people use the softmac driver without a
postfix at all.
I'm sorry. That's not our problem. ;)
That's either a distro or user problem
-by: Matthew Garrett [EMAIL PROTECTED]
---
diff -urp bcm43xx-fwcutter-006/fwcutter.c bcm43xx-fwcutter-006.new/fwcutter.c
--- bcm43xx-fwcutter-006/fwcutter.c 2006-12-08 21:00:28.0 +
+++ bcm43xx-fwcutter-006.new/fwcutter.c 2007-01-26 13:42:08.0 +
@@ -28,6 +28,7
This patch alters the dscape version of the bcm43xx driver to explicitly
request version 4 firmware.
Signed-off-by: Matthew Garrett [EMAIL PROTECTED]
---
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
index 9f4d51d..4f11ce8
. The alternative is that distributions
are going to have to ship modprobe.d files for the dscape driver, which
will probably result in different vendors choosing different suffixes.
The two firmwares are incompatible in any meaningful way, so surely they
should have different names?
--
Matthew
for distributions to handle. Adding a suggestion to the docs that
people use v4 as the postfix for dscape would probably be adequate, I
just want to avoid the situation where different distributions use
different postfixes and everyone gets confused.
--
Matthew Garrett | [EMAIL PROTECTED
On Tue, Apr 04, 2006 at 09:13:29AM +0200, Thomas Ploch wrote:
How do I configure syslog, that it logs the kernel panics as well, because
only successfull start-ups get logged somehow.
Is it in syslog.conf:
In most cases, you can't. You'll have to copy it down by hand.
--
Matthew Garrett
. I
cant give you any logs, because the panics dont get logged. Im getting sad
:(
If you provide the full text of the kernel panic, then there is some
chance of people being able to help you - otherwise, I'm afraid it's
impossible.
--
Matthew Garrett | [EMAIL PROTECTED
On Wed, Mar 08, 2006 at 02:41:58PM +0100, Johannes Berg wrote:
But this one is a 4312 no? It's getting confusing :)
Yeah. I can't find any real reference to the 4312, so it's quite
possible that it's just a b/g version of the 4311.
--
Matthew Garrett | [EMAIL PROTECTED
On Wed, Mar 08, 2006 at 03:15:54PM +0100, Johannes Berg wrote:
Matthew Garrett wrote:
On Wed, Mar 08, 2006 at 02:41:58PM +0100, Johannes Berg wrote:
But this one is a 4312 no? It's getting confusing :)
Yeah. I can't find any real reference to the 4312, so it's quite
possible that it's
that it's wrong, in which case it's just a b/g card. I don't have any
way of testing, unfortunately.
--
Matthew Garrett | [EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
On Tue, Mar 07, 2006 at 12:30:59PM +, Matthew Garrett wrote:
Various places seem to be claiming that the new Macs all have 802.11a,
but I can't actually find anyone who's tested that. So it's possible
that it's wrong, in which case it's just a b/g card. I don't have any
way of testing
what the right thing to do there is.
With this patch, I can associate, DHCP and transmit and receive data.
Signed-off-by: Matthew Garrett [EMAIL PROTECTED]
--
Matthew Garrett | [EMAIL PROTECTED]
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx.h
b/drivers/net/wireless/bcm43xx/bcm43xx.h
index
32 matches
Mail list logo
