On Monday 25 February 2008 13:11:04 Pekka Enberg wrote:
> On Mon, Feb 25, 2008 at 11:54 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > > Isn't the resolution Michael is suggesting is, "use the different
> > driver"?
> >
> > I have two resolut
On Monday 25 February 2008 11:49:34 Xavier Bestel wrote:
> On Mon, 2008-02-25 at 11:38 +0100, Michael Buesch wrote:
> > [1] bcm43xx is unmaintained. Larry used to be the maintainer until
> > he dropped it a few months ago.
>
> Doesn't that mean that Alexey gets to be th
On Monday 25 February 2008 11:23:02 Alexey Zaytsev wrote:
> On Mon, Feb 25, 2008 at 9:49 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote:
> > > Hi Michael,
> > >
> > > On Sun, 24 Feb 20
On Monday 25 February 2008 07:49:35 Greg KH wrote:
> On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote:
> > Hi Michael,
> >
> > On Sun, 24 Feb 2008, Michael Buesch wrote:
> > > > The ony way I see this was possible, you manually changed the
On Monday 25 February 2008 07:49:35 Greg KH wrote:
On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote:
Hi Michael,
On Sun, 24 Feb 2008, Michael Buesch wrote:
The ony way I see this was possible, you manually changed the
module loading order, so that the b43xx module
On Monday 25 February 2008 11:23:02 Alexey Zaytsev wrote:
On Mon, Feb 25, 2008 at 9:49 AM, Greg KH [EMAIL PROTECTED] wrote:
On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote:
Hi Michael,
On Sun, 24 Feb 2008, Michael Buesch wrote:
The ony way I see
On Monday 25 February 2008 11:49:34 Xavier Bestel wrote:
On Mon, 2008-02-25 at 11:38 +0100, Michael Buesch wrote:
[1] bcm43xx is unmaintained. Larry used to be the maintainer until
he dropped it a few months ago.
Doesn't that mean that Alexey gets to be the maintainer, as he's the one
On Monday 25 February 2008 13:11:04 Pekka Enberg wrote:
On Mon, Feb 25, 2008 at 11:54 AM, Michael Buesch [EMAIL PROTECTED] wrote:
Isn't the resolution Michael is suggesting is, use the different
driver?
I have two resolutions. One being:
rmmod b44
rmmod ssb
modprobe bcm43xx
On Sunday 24 February 2008, Alexey Zaytsev wrote:
> On Sun, Feb 24, 2008 at 5:29 PM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > On Saturday 23 February 2008 12:32:50 Alexey Zaytsev wrote:
> > > The problem is not with enabling both b43 and bcm43xx (will, whis won't
On Saturday 23 February 2008 12:32:50 Alexey Zaytsev wrote:
> The problem is not with enabling both b43 and bcm43xx (will, whis won't work
> anyway, and there is no chance fixing it). The problem is with enabling the
> bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then
>
On Saturday 23 February 2008 12:32:50 Alexey Zaytsev wrote:
The problem is not with enabling both b43 and bcm43xx (will, whis won't work
anyway, and there is no chance fixing it). The problem is with enabling the
bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then
wrongly
On Sunday 24 February 2008, Alexey Zaytsev wrote:
On Sun, Feb 24, 2008 at 5:29 PM, Michael Buesch [EMAIL PROTECTED] wrote:
On Saturday 23 February 2008 12:32:50 Alexey Zaytsev wrote:
The problem is not with enabling both b43 and bcm43xx (will, whis won't
work
anyway
On Saturday 23 February 2008 22:32:46 Alexey Zaytsev wrote:
> > The insults being? A few quotes, please.
> If you really want to know, the
> "Because the new driver works, if you just set it up right."
> for me was clearly a hint that I'm just an other imcompetent
> user, who can't even follow
On Saturday 23 February 2008 17:44:33 Ingo Molnar wrote:
>
> * Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > On Saturday 23 February 2008 12:07:51 Ingo Molnar wrote:
> > > I have to say, after having observed multiple incidents around b43 in
> > > the p
On Saturday 23 February 2008 12:07:51 Ingo Molnar wrote:
> I have to say, after having observed multiple incidents around b43 in
> the past few months you are one of the worst driver maintainers i've
> ever seen on lkml: you are ignoring regressions, you are frequently
> insulting our testers
On Saturday 23 February 2008 14:17:55 Alexey Zaytsev wrote:
> diff --git a/drivers/net/wireless/bcm43xx/Kconfig
> b/drivers/net/wireless/bcm43xx/Kconfig
> index 0159701..afb8f43 100644
> --- a/drivers/net/wireless/bcm43xx/Kconfig
> +++ b/drivers/net/wireless/bcm43xx/Kconfig
> @@ -1,6 +1,6 @@
>
It turns out that I rewrote the HWRNG core once to make it
pluggable, but I'm not a crypto-expert at all. So I'm
certainly the wrong person for being a maintainer of
the HWRNG core. Let's orphan it.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-testing/MAINT
On Saturday 23 February 2008 12:07:51 Ingo Molnar wrote:
>
> * Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > > If this is not a repgession, than I don't know what is. And if it is
> > > a regression, it should be fixed at least in the 2.6.24.y series, do
>
On Saturday 23 February 2008 11:14:23 Gordon Farquharson wrote:
> On Fri, Feb 22, 2008 at 10:51 PM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > A big fat comment is something like that:
> >
> > /* Explicit padding to support a broken sanity check in file2alias.c.
>
On Saturday 23 February 2008 12:07:51 Ingo Molnar wrote:
* Michael Buesch [EMAIL PROTECTED] wrote:
If this is not a repgession, than I don't know what is. And if it is
a regression, it should be fixed at least in the 2.6.24.y series, do
you agree?
No. Playing with kconfig
It turns out that I rewrote the HWRNG core once to make it
pluggable, but I'm not a crypto-expert at all. So I'm
certainly the wrong person for being a maintainer of
the HWRNG core. Let's orphan it.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-testing/MAINTAINERS
On Saturday 23 February 2008 14:17:55 Alexey Zaytsev wrote:
diff --git a/drivers/net/wireless/bcm43xx/Kconfig
b/drivers/net/wireless/bcm43xx/Kconfig
index 0159701..afb8f43 100644
--- a/drivers/net/wireless/bcm43xx/Kconfig
+++ b/drivers/net/wireless/bcm43xx/Kconfig
@@ -1,6 +1,6 @@
config
On Saturday 23 February 2008 11:14:23 Gordon Farquharson wrote:
On Fri, Feb 22, 2008 at 10:51 PM, Michael Buesch [EMAIL PROTECTED] wrote:
A big fat comment is something like that:
/* Explicit padding to support a broken sanity check in file2alias.c.
* The check will compare the size
On Saturday 23 February 2008 12:07:51 Ingo Molnar wrote:
I have to say, after having observed multiple incidents around b43 in
the past few months you are one of the worst driver maintainers i've
ever seen on lkml: you are ignoring regressions, you are frequently
insulting our testers and
On Saturday 23 February 2008 17:44:33 Ingo Molnar wrote:
* Michael Buesch [EMAIL PROTECTED] wrote:
On Saturday 23 February 2008 12:07:51 Ingo Molnar wrote:
I have to say, after having observed multiple incidents around b43 in
the past few months you are one of the worst driver
On Saturday 23 February 2008 22:32:46 Alexey Zaytsev wrote:
The insults being? A few quotes, please.
If you really want to know, the
Because the new driver works, if you just set it up right.
for me was clearly a hint that I'm just an other imcompetent
user, who can't even follow the
On Friday 22 February 2008, Alexey Zaytsev wrote:
> Well, it looks like Michael is not the bcm43xx maintaner. I sent the
> patch to him,
> because it was his code that broke the driver, and I thought it would
> be easy for him to review my patch, as it touches his code.
See? I'm tired of this
On Saturday 23 February 2008, Gordon Farquharson wrote:
> On Fri, Feb 22, 2008 at 7:07 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > On Friday 22 February 2008 05:24:32 Gordon Farquharson wrote:
> > > On Wed, Feb 20, 2008 at 12:37 PM, Sam Ravnborg &
On Friday 22 February 2008 21:06:00 Alexey Zaytsev wrote:
> > It is not my problem, if you refuse to use b43.
> > You also still refuse to tell me details about your card and _what_
> > does not work. I do own lots of different card and they
> > all work fine with b43. There's one exception,
On Friday 22 February 2008 18:51:32 Gabriel C wrote:
> > I'm not going to play these kconfig SELECT tricks anymore.
>
> Fix it different then.
Please do so.
> Yes it is but that is still not a valid reason to NACK that patch , I'm sorry.
NACK means I (being the maintainer of the modified code)
On Friday 22 February 2008 19:10:39 Alexey Zaytsev wrote:
> Sorry, I don't get it. You are going to remove the (somehow)
> working driver, while there are known problems with the new
> one? Why?
Because the new driver works, if you just set it up right.
Until now every "breakage" was just a usage
On Friday 22 February 2008 12:17:15 Alexey Zaytsev wrote:
>
> Hello.
>
> The bcm43xx driver won't work any more, if the b44 Ethernet
> driver is enabled. This happens because the b44 driver
> needlessly enables the b43_pci_bridge code, which claims
> the same pci ids as the bcm43xx driver. The
On Friday 22 February 2008 05:24:32 Gordon Farquharson wrote:
> Hi Sam
>
> On Wed, Feb 20, 2008 at 12:37 PM, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > Option 1) is the worst of the three as that can cost
> > of many hours bug-hunting.
> > Option 3) may seem optimal but I do not like to
On Friday 22 February 2008 05:24:32 Gordon Farquharson wrote:
Hi Sam
On Wed, Feb 20, 2008 at 12:37 PM, Sam Ravnborg [EMAIL PROTECTED] wrote:
Option 1) is the worst of the three as that can cost
of many hours bug-hunting.
Option 3) may seem optimal but I do not like to add more
On Friday 22 February 2008 12:17:15 Alexey Zaytsev wrote:
Hello.
The bcm43xx driver won't work any more, if the b44 Ethernet
driver is enabled. This happens because the b44 driver
needlessly enables the b43_pci_bridge code, which claims
the same pci ids as the bcm43xx driver. The
On Friday 22 February 2008 19:10:39 Alexey Zaytsev wrote:
Sorry, I don't get it. You are going to remove the (somehow)
working driver, while there are known problems with the new
one? Why?
Because the new driver works, if you just set it up right.
Until now every breakage was just a usage
On Friday 22 February 2008 18:51:32 Gabriel C wrote:
I'm not going to play these kconfig SELECT tricks anymore.
Fix it different then.
Please do so.
Yes it is but that is still not a valid reason to NACK that patch , I'm sorry.
NACK means I (being the maintainer of the modified code)
On Friday 22 February 2008 21:06:00 Alexey Zaytsev wrote:
It is not my problem, if you refuse to use b43.
You also still refuse to tell me details about your card and _what_
does not work. I do own lots of different card and they
all work fine with b43. There's one exception, the 4311
On Friday 22 February 2008, Alexey Zaytsev wrote:
Well, it looks like Michael is not the bcm43xx maintaner. I sent the
patch to him,
because it was his code that broke the driver, and I thought it would
be easy for him to review my patch, as it touches his code.
See? I'm tired of this how
On Saturday 23 February 2008, Gordon Farquharson wrote:
On Fri, Feb 22, 2008 at 7:07 AM, Michael Buesch [EMAIL PROTECTED] wrote:
On Friday 22 February 2008 05:24:32 Gordon Farquharson wrote:
On Wed, Feb 20, 2008 at 12:37 PM, Sam Ravnborg [EMAIL PROTECTED] wrote:
Option 1
On Wednesday 20 February 2008 01:44:38 Gordon Farquharson wrote:
> Hi Michael
>
> On Feb 19, 2008 3:41 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > > [2]
> > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7492
On Wednesday 20 February 2008 01:44:38 Gordon Farquharson wrote:
Hi Michael
On Feb 19, 2008 3:41 AM, Michael Buesch [EMAIL PROTECTED] wrote:
[2]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7492d4a416d68ab4bd254b36ffcc4e0138daa8ff
That doesn't
On Tuesday 19 February 2008 05:59:21 Gordon Farquharson wrote:
> Does this thread [1] provide any clues as to the Right Thing (TM) to do?
>
> It should be noted that Linus and Andrew signed off on the m68k fix
> [2]. I'm CC'ing them and Al Viro on this email to solicit their input.
>
> Gordon
>
On Tuesday 19 February 2008 09:37:05 Geert Uytterhoeven wrote:
> On Tue, 19 Feb 2008, Michael Buesch wrote:
> > Still I can't see why this structure will cause alignment issues, as the
> > compiler will pad it up to the right boundary automagically, as you said
> > above
On Tuesday 19 February 2008 09:37:05 Geert Uytterhoeven wrote:
On Tue, 19 Feb 2008, Michael Buesch wrote:
Still I can't see why this structure will cause alignment issues, as the
compiler will pad it up to the right boundary automagically, as you said
above. Why doesn't the ARM compiler do
On Tuesday 19 February 2008 05:59:21 Gordon Farquharson wrote:
Does this thread [1] provide any clues as to the Right Thing (TM) to do?
It should be noted that Linus and Andrew signed off on the m68k fix
[2]. I'm CC'ing them and Al Viro on this email to solicit their input.
Gordon
[1]
On Tuesday 19 February 2008 00:42:12 Sam Ravnborg wrote:
> On Tue, Feb 19, 2008 at 12:17:04AM +0100, Michael Buesch wrote:
> > On Tuesday 19 February 2008 00:00:58 Russell King wrote:
> > > > > Why can't we have an array of this structure on ARM?
> > > &g
On Tuesday 19 February 2008 00:00:58 Russell King wrote:
> > > Why can't we have an array of this structure on ARM?
> > >
> > > struct ssb_device_id {
> > >__u16 vendor;
> >
> > 2 bytes
> >
> > >__u16 coreid;
> >
> > 2 bytes
> >
> > >__u8revision;
> >
> > 1
On Monday 18 February 2008 23:53:54 Russell King wrote:
> I get extremely pissed off everytime I have to try to explain random
> alignment issues to people. "It doesn't work like i386 so it must be
> broken" is a rediculous position to take.
I did _not_ ask for a general description of
On Monday 18 February 2008 23:50:30 Harvey Harrison wrote:
> On Mon, 2008-02-18 at 23:43 +0100, Michael Buesch wrote:
> > On Monday 18 February 2008 23:34:10 Russell King wrote:
> > >
> > > Well, don't expect this driver to work until you fix your broken
> &
On Monday 18 February 2008 23:34:10 Russell King wrote:
> On Mon, Feb 18, 2008 at 11:24:44PM +0100, Michael Buesch wrote:
> > On Monday 18 February 2008 23:13:24 Russell King wrote:
> > > On Mon, Feb 18, 2008 at 11:08:56PM +0100, Michael Buesch wrote:
> > > > On Mo
On Monday 18 February 2008 23:13:24 Russell King wrote:
> On Mon, Feb 18, 2008 at 11:08:56PM +0100, Michael Buesch wrote:
> > On Monday 18 February 2008 23:03:10 Gordon Farquharson wrote:
> > > The b43 driver in 2.6.25-rc[12] fails to build for arm on an x86_64
> > >
On Monday 18 February 2008 23:03:10 Gordon Farquharson wrote:
> The b43 driver in 2.6.25-rc[12] fails to build for arm on an x86_64
> box using a cross-compiler:
>
> FATAL: drivers/net/wireless/b43/b43: sizeof(struct ssb_device_id)=6 is
> not a modulo of the size of section
On Monday 18 February 2008 11:02:57 Aurelien Jarno wrote:
> Switch the SSB PCI core driver to the new SPROM data structure now that
> the old one has been removed.
>
> Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
Jo
On Monday 18 February 2008 11:02:57 Aurelien Jarno wrote:
Switch the SSB PCI core driver to the new SPROM data structure now that
the old one has been removed.
Signed-off-by: Aurelien Jarno [EMAIL PROTECTED]
Acked-by: Michael Buesch [EMAIL PROTECTED]
John, can you please apply
On Monday 18 February 2008 23:03:10 Gordon Farquharson wrote:
The b43 driver in 2.6.25-rc[12] fails to build for arm on an x86_64
box using a cross-compiler:
FATAL: drivers/net/wireless/b43/b43: sizeof(struct ssb_device_id)=6 is
not a modulo of the size of section __mod_ssb_device_table=64.
On Monday 18 February 2008 23:34:10 Russell King wrote:
On Mon, Feb 18, 2008 at 11:24:44PM +0100, Michael Buesch wrote:
On Monday 18 February 2008 23:13:24 Russell King wrote:
On Mon, Feb 18, 2008 at 11:08:56PM +0100, Michael Buesch wrote:
On Monday 18 February 2008 23:03:10 Gordon
On Monday 18 February 2008 23:13:24 Russell King wrote:
On Mon, Feb 18, 2008 at 11:08:56PM +0100, Michael Buesch wrote:
On Monday 18 February 2008 23:03:10 Gordon Farquharson wrote:
The b43 driver in 2.6.25-rc[12] fails to build for arm on an x86_64
box using a cross-compiler
On Monday 18 February 2008 23:53:54 Russell King wrote:
I get extremely pissed off everytime I have to try to explain random
alignment issues to people. It doesn't work like i386 so it must be
broken is a rediculous position to take.
I did _not_ ask for a general description of alignment. I
On Tuesday 19 February 2008 00:00:58 Russell King wrote:
Why can't we have an array of this structure on ARM?
struct ssb_device_id {
__u16 vendor;
2 bytes
__u16 coreid;
2 bytes
__u8revision;
1 byte
};
and therefore
On Monday 18 February 2008 23:50:30 Harvey Harrison wrote:
On Mon, 2008-02-18 at 23:43 +0100, Michael Buesch wrote:
On Monday 18 February 2008 23:34:10 Russell King wrote:
Well, don't expect this driver to work until you fix your broken
assumptions about alignment requirements
On Tuesday 19 February 2008 00:42:12 Sam Ravnborg wrote:
On Tue, Feb 19, 2008 at 12:17:04AM +0100, Michael Buesch wrote:
On Tuesday 19 February 2008 00:00:58 Russell King wrote:
Why can't we have an array of this structure on ARM?
struct ssb_device_id {
__u16
On Wednesday 30 January 2008 21:02:47 Adrian Bunk wrote:
> b43_mac_{enable,suspend}() can now become static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
> ---
>
> drivers/net/wireless/b43/main.c |4 ++--
>
On Wednesday 30 January 2008 21:02:47 Adrian Bunk wrote:
b43_mac_{enable,suspend}() can now become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Michael Buesch [EMAIL PROTECTED]
---
drivers/net/wireless/b43/main.c |4 ++--
drivers/net/wireless/b43/main.h |3
f attempting to unregister device objects
> > locked by the PM core during suspend/resume cycles. Also, make it
> > use a suspend-safe method of unregistering device object in the
> > resume error path.
> >
> > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
locked by the PM core during suspend/resume cycles. Also, make it
use a suspend-safe method of unregistering device object in the
resume error path.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Michael Buesch [EMAIL PROTECTED]
Maybe we should have global
On Monday 07 January 2008 21:23:44 Alejandro Riveira Fernández wrote:
> > > [ 37.043990] WARNING: at
> > > /home/alex/kernel/linux-2.6/net/mac80211/rx.c:1486 __ieee80211_rx()
> > > [ 37.043996] Pid: 0, comm: swapper Not tainted 2.6.24-rc7 #3
> > >
On Monday 07 January 2008 21:23:44 Alejandro Riveira Fernández wrote:
[ 37.043990] WARNING: at
/home/alex/kernel/linux-2.6/net/mac80211/rx.c:1486 __ieee80211_rx()
[ 37.043996] Pid: 0, comm: swapper Not tainted 2.6.24-rc7 #3
On Monday 07 January 2008 17:52:48 Alejandro Riveira Fernández wrote:
> El Mon, 7 Jan 2008 17:24:03 +0100
> Michael Buesch <[EMAIL PROTECTED]> escribió:
>
>
>
> >
>
On Monday 07 January 2008 17:14:15 Alejandro Riveira Fernández wrote:
> El Sun, 6 Jan 2008 14:19:16 -0800 (PST)
> Linus Torvalds <[EMAIL PROTECTED]> escribió:
>
> >
> > It's been two weeks since rc6, but let's face it, with xmas and new years
> > (and birthdays) in between, there hasn't
On Monday 07 January 2008 17:14:15 Alejandro Riveira Fernández wrote:
El Sun, 6 Jan 2008 14:19:16 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] escribió:
It's been two weeks since rc6, but let's face it, with xmas and new years
(and birthdays) in between, there hasn't actually been a
On Monday 07 January 2008 17:52:48 Alejandro Riveira Fernández wrote:
El Mon, 7 Jan 2008 17:24:03 +0100
Michael Buesch [EMAIL PROTECTED] escribió:
Can you post the lines above this?
This might
On Friday 04 January 2008 23:05:54 Miguel Botón wrote:
> This patch fixes a compilation warning in 'iwl-4965.c'.
>
> Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c
> b/drivers/net/wireless/iwlwifi/iwl-4965.c
> index 74999af..92237cd
On Friday 04 January 2008 23:05:54 Miguel Botón wrote:
This patch fixes a compilation warning in 'iwl-4965.c'.
Signed-off-by: Miguel Botón [EMAIL PROTECTED]
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c
b/drivers/net/wireless/iwlwifi/iwl-4965.c
index 74999af..92237cd 100644
---
On Tuesday 01 January 2008 01:16:46 Miguel Botón wrote:
> This patch adds the 'ssb_pcihost_set_power_state' function.
>
> This function allows us to set the power state of a PCI device
> (for example b44 ethernet device).
>
> Signed-off-by: Miguel Botón <[EMAIL PROTECTED
On Monday 31 December 2007 19:37:43 Torsten Kaiser wrote:
> The base problem is that there already are many options to break
> external modules. (CONFIG_MODULES=n ;) )
Exactly. There already are enough ways to break external modules.
No need to introduce more. ;)
> The question I can't answer in
On Monday 31 December 2007 17:38:03 Alan Cox wrote:
> On Mon, 31 Dec 2007 17:17:19 +0100
> "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
>
> > a) this could be disabled during development if you want this
> > b) this would even only affect development if you add new code that
> > now needs a
On Monday 31 December 2007 16:55:57 Torsten Kaiser wrote:
> On Dec 31, 2007 3:42 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the
> > theoretical possibility of CONIG_UNIX=m waste a few hundred bytes
> > of memory.
>
> One thing I
On Monday 31 December 2007 16:55:57 Torsten Kaiser wrote:
On Dec 31, 2007 3:42 PM, Adrian Bunk [EMAIL PROTECTED] wrote:
With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the
theoretical possibility of CONIG_UNIX=m waste a few hundred bytes
of memory.
One thing I always
On Monday 31 December 2007 17:38:03 Alan Cox wrote:
On Mon, 31 Dec 2007 17:17:19 +0100
Torsten Kaiser [EMAIL PROTECTED] wrote:
a) this could be disabled during development if you want this
b) this would even only affect development if you add new code that
now needs a EXPORT_SYMBOL that
On Monday 31 December 2007 19:37:43 Torsten Kaiser wrote:
The base problem is that there already are many options to break
external modules. (CONFIG_MODULES=n ;) )
Exactly. There already are enough ways to break external modules.
No need to introduce more. ;)
The question I can't answer in
On Tuesday 01 January 2008 01:16:46 Miguel Botón wrote:
This patch adds the 'ssb_pcihost_set_power_state' function.
This function allows us to set the power state of a PCI device
(for example b44 ethernet device).
Signed-off-by: Miguel Botón [EMAIL PROTECTED]
Acked-by: Michael Buesch
On Sunday 23 December 2007 20:39:18 Larry Finger wrote:
> With 2.6.24-rc5, a b43 user reports a problem at bootup. The b43 module,
> which should be loaded by
> the ssb module, fails with the following type of message:
>
> ssb: Sonics Silicon Backplane found on PCI device :0c:00.0
> b43:
On Sunday 23 December 2007 20:39:18 Larry Finger wrote:
With 2.6.24-rc5, a b43 user reports a problem at bootup. The b43 module,
which should be loaded by
the ssb module, fails with the following type of message:
ssb: Sonics Silicon Backplane found on PCI device :0c:00.0
b43: disagrees
On Tuesday 18 December 2007 00:12:30 [EMAIL PROTECTED] wrote:
> On Dec 17, 2007 5:45 PM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> >
> > Ehm, excuse me.
> > What are you doing exactly? In this thread you told me you have
> > a device which requires b43:
> >
On Monday 17 December 2007 23:04:37 [EMAIL PROTECTED] wrote:
> On Dec 17, 2007 5:35 AM, <[EMAIL PROTECTED]> wrote:
> > If this is a mac80211 related problem, then other systems connecting
> > to the same ap and using mac80211 would also be affected? Like I said
> > earlier, there are five
On Monday 17 December 2007 08:17:58 [EMAIL PROTECTED] wrote:
> On Dec 17, 2007 1:52 AM, Larry Finger <[EMAIL PROTECTED]> wrote:
> >
> > One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the
> > former always used a fixed
> > rate; whereas mac80211 tries to adjust the bit rate
On Monday 17 December 2007 08:17:58 [EMAIL PROTECTED] wrote:
On Dec 17, 2007 1:52 AM, Larry Finger [EMAIL PROTECTED] wrote:
One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the
former always used a fixed
rate; whereas mac80211 tries to adjust the bit rate according
On Monday 17 December 2007 23:04:37 [EMAIL PROTECTED] wrote:
On Dec 17, 2007 5:35 AM, [EMAIL PROTECTED] wrote:
If this is a mac80211 related problem, then other systems connecting
to the same ap and using mac80211 would also be affected? Like I said
earlier, there are five machines
On Tuesday 18 December 2007 00:12:30 [EMAIL PROTECTED] wrote:
On Dec 17, 2007 5:45 PM, Michael Buesch [EMAIL PROTECTED] wrote:
Ehm, excuse me.
What are you doing exactly? In this thread you told me you have
a device which requires b43:
Well, I'm not sure what you mean by requires b43
On Sunday 16 December 2007 10:22:43 Ingo Molnar wrote:
>
> * John W. Linville <[EMAIL PROTECTED]> wrote:
>
> > > It's not that simple. For example, regression testing will be a
> > > major PITA if one needs to switch back and forth from the new driver
> > > to the old one in the process.
> >
On Sunday 16 December 2007 03:30:16 Larry Finger wrote:
> Michael Buesch wrote:
> > On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
> >> Well, the only problem with that is I suspect there are some "newer" cards
> >> that
> >> work bette
On Sunday 16 December 2007 03:30:16 Larry Finger wrote:
Michael Buesch wrote:
On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
Well, the only problem with that is I suspect there are some newer cards
that
work better with v3 firmware, although they are supposed to support
On Sunday 16 December 2007 10:22:43 Ingo Molnar wrote:
* John W. Linville [EMAIL PROTECTED] wrote:
It's not that simple. For example, regression testing will be a
major PITA if one needs to switch back and forth from the new driver
to the old one in the process.
Not really
On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
> Well, the only problem with that is I suspect there are some "newer" cards
> that
> work better with v3 firmware, although they are supposed to support both.
And I suspect that you are wrong until you show me one. :)
--
Greetings
On Saturday 15 December 2007 01:51:47 Rafael J. Wysocki wrote:
> On Friday, 14 of December 2007, Michael Buesch wrote:
> > On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote:
> > > > This user did get the following messages in dmesg:
> > > >
> >
On Saturday 15 December 2007 01:51:47 Rafael J. Wysocki wrote:
On Friday, 14 of December 2007, Michael Buesch wrote:
On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote:
This user did get the following messages in dmesg:
b43err(dev-wl, Firmware file \%s\ not found
On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
Well, the only problem with that is I suspect there are some newer cards
that
work better with v3 firmware, although they are supposed to support both.
And I suspect that you are wrong until you show me one. :)
--
Greetings
On Friday 14 December 2007 20:55:43 Ray Lee wrote:
> Oh. My. God.
>
> Michael. I have a degree in Physics. I placed sixth in the world
> finals of the ACM Collegiate programming contest in 1999, Cal Poly
> Team Gold. ( http://icpc.baylor.edu/past/icpc99/Finals/Tour/Win/Win.html
> , I'm the guy
On Friday 14 December 2007 20:25:39 Ray Lee wrote:
> > I'm sorry. The patch that _you_ quoted fixes a blinking LED
> > and nothing else.
>
> Well, you're wrong. Sorry, but that's just the way it is. See below.
>
> > It does _not_ fix loading of rfkill or b43 in any way.
> > It does, however, fix
1 - 100 of 419 matches
Mail list logo
