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 re
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 t
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 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
> wron
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 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 an
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 @@
> co
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: wireles
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 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 &
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, th
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 b4
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
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 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
> >
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 byt
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.
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 __mod_ssb_device_table=
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, c
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 ++--
>
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]>
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 actually
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 10064
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
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 EXPORT_
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 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: disa
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 machines
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 a
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 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 Mi
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 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 all
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
On Friday 14 December 2007 19:45:02 Ray Lee wrote:
> > > One problem related to b43 source code, patch exists, has yet to be
> > > merged upstream.
> >
> > Yeah. A problem preventing a LED from blinking.
> > That's a real regression Come on. Stop that bullshit.
>
> I'm going to say this one la
On Friday 14 December 2007 18:59:10 Ingo Molnar wrote:
>
> * Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > In my opinion this all is the work of the distributions and not the
> > work of the kernel developers. Distributions have to make sure that
> > every
On Friday 14 December 2007 19:01:51 Ray Lee wrote:
> No, I don't have module autoloading disabled. modprobe-ing b43
> automatically loads ssb. Neither, however, will load rfkill or
> rfkill-input. And if they aren't loaded, then b43/ssb are *completely*
> silent during load. Nothing to dmesg at all
On Friday 14 December 2007 17:45:52 Ray Lee wrote:
> On Dec 14, 2007 8:27 AM, Ray Lee <[EMAIL PROTECTED]> wrote:
> > On Dec 14, 2007 6:40 AM, <[EMAIL PROTECTED]> wrote:
> > > Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo
> > > suggests other ways to smooth out the transition. I h
On Friday 14 December 2007 17:06:39 Ray Lee wrote:
> Hi all. Perhaps I can inject some facts into this?
>
> On Dec 14, 2007 5:08 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > > > This user did get the following messages in dmesg:
> > > >
> > > &
On Friday 14 December 2007 13:53:27 Ingo Molnar wrote:
>
> * Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > This user did get the following messages in dmesg:
> >
> > b43err(dev->wl, "Firmware file \"%s\" not found "
> >
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 "
> >"or load failed.\n", path);
>
> So the question seems to be why b43 needs version 4, when b43legacy and
> bcm
On Friday 14 December 2007 13:16:17 Ingo Molnar wrote:
>
> * Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > > The testers who did nothing but reported that the new driver did not
> > > work on their hardware.
> >
> > Which testers?
&
/wireless/bcm43xx/ | tail -10
> 2 Sam Ravnborg
> 3 David Howells
> 3 David Woodhouse
> 3 Joe Perches
> 4 Jeff Garzik
> 5 Daniel Drake
> 6 Stefano Brivio
> 9 John W. Linville
> 48 Larry Finger
> 80 Michael Bu
On Friday 14 December 2007 02:12:25 Ray Lee wrote:
> Digging a little farther into it, it looks like b43 is barfing partway
> through init as the firmware file it's looking for has changed names.
> Perhaps that's the issue. I'll take a longer look at this all
> tomorrow.
http://www.linuxwireless.o
On Friday 14 December 2007 01:55:50 Harvey Harrison wrote:
> On Fri, 2007-12-14 at 01:43 +0100, Michael Buesch wrote:
> > Oh come on. b43 is more than a year old now. How long should we wait?
> > Two or three? Forever?
> >
>
> Any pointers to the advantages of b43?
h
On Friday 14 December 2007 01:05:00 Ray Lee wrote:
> Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
> realize that. Hopefully that'll be automatic soon. Regardless, upon
> doing so, and loading ssb and b43, it sees my card, but is still not
> fully functional. iwconfig sees:
>
> l
On Thursday 13 December 2007 02:17:16 Ray Lee wrote:
> On Dec 12, 2007 4:48 PM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > This driver is scheduled for removal, so I'd not touch it anymore
> > to avoid the possibility to introduce a lastminute regression.
> > Th
On Thursday 13 December 2007 11:13:27 Ingo Molnar wrote:
>
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > This driver is scheduled for removal, so I'd not touch it anymore to
> > > avoid the possibility to introduce a lastminute regression. The new
> > > drivers (b43 and b43legacy) have t
On Wednesday 12 December 2007 09:00:03 Daniel Walker wrote:
>
> Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
>
> ---
> drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c | 30
> -
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
> Index: linux-2.6.23/drivers/net/
On Saturday 08 December 2007 16:33:27 Ingo Molnar wrote:
>
> * Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > On Saturday 08 December 2007 16:13:41 Ingo Molnar wrote:
> > >
> > > * Mark Lord <[EMAIL PROTECTED]> wrote:
> > >
> > >
On Saturday 08 December 2007 16:13:41 Ingo Molnar wrote:
>
> * Mark Lord <[EMAIL PROTECTED]> wrote:
>
> > Ingo Molnar wrote:
> >> ...
> >> thanks. I do get the impression that most of this can/should wait until
> >> 2.6.25. The patches look quite dangerous.
> > ..
> >
> > I confess to not really
On Friday 23 November 2007 23:29:28 Jean Delvare wrote:
> On Fri, 23 Nov 2007 17:00:52 +0100, Michael Buesch wrote:
> > This patch fixes my crash problem.
>
> Out of curiosity, what kind of crash was it? I admit that I can't see
> how the code could crash.
>
It's
t; slower just for the sake of monitors which I guess nobody uses
> anymore. Can't we just get rid of it?
This patch fixes my crash problem.
Thanks a lot guys!
> Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
> ---
> dr
On Wednesday 21 November 2007 20:58:09 Benjamin Herrenschmidt wrote:
>
> > > Can you try the patch from Jean that I pasted below and let us know if
> > > it helps ? It looks like the releasing of the i2c lines may have been
> > > done backward.
> >
> > This patch fixes the problem. The monitor s
On Monday 19 November 2007 19:25:25 Patrick McHardy wrote:
> Michael Buesch wrote:
> > On Sunday 18 November 2007 22:32:52 Patrick McHardy wrote:
> >> These patches add support for using the HIFN rng.
> >
> > Acked-by: Michael Buesch <[EMAIL PROTECTED]>
On Sunday 18 November 2007 22:32:52 Patrick McHardy wrote:
> These patches add support for using the HIFN rng.
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
Patrick, can you send this patchset to Andrew for inclusion into -mm?
--
Greetings Michael.
-
To unsubscribe from this list:
On Sunday 18 November 2007 05:04:01 Herbert Xu wrote:
> On Sun, Nov 18, 2007 at 04:30:40AM +0100, Patrick McHardy wrote:
> >
> > On a related issue, I think the rng interface is not very suitable
> > for chips like HIFN that have a constant random bandwidth, it would
> > make a lot more sense to re
() or
> > > kmem_cache_free().
>
> On 11/5/07, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > Yeah.
> >
> > What I also saw was random "one-bit-errors" once and then on rmmod of
> > modules.
> > I have absolutely no idea how they were caused
On Monday 05 November 2007 13:23:50 Pekka Enberg wrote:
> Hi Michael,
>
> On Sat, 2007-11-03 at 21:06 +0100, Michael Buesch wrote:
> > Who is responsible for slab btw?
> > I mean, someone should be interested in getting this bug fixed. :)
> > When using slab I see
On Thursday 01 November 2007 08:19:02 Matthias Kaehlcke wrote:
> Prism54: Convert mgmt_sem to the mutex API
>
> Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
>
> --
>
> diff --git a/drivers/net/wireless/prism54/islpci_dev.c
> b/drivers/net/wireless/prism54/islpci_dev.c
> index 219dd65..d
On Saturday 03 November 2007 20:58:09 Luis R. Rodriguez wrote:
> I was using SLAB and ran into other strange oops, as the one below,
> but after switching to SLUB, after Michael Buesch's suggestion that
> one went away... The lockdep segfault is still present, however.
Who is responsible for slab
On Wednesday 24 October 2007 21:31:21 Miguel Botón wrote:
> Add "ssb_pci_set_power_state" function. This allows set the power state of a
> PCI device (for example b44 ethernet device).
>
> diff -ruN linux-2.6.23/include/linux/ssb/ssb.h
> linux-2.6.23.orig/include/linux/ssb/ssb.h
> --- linux-2.6.
resigned as maintainer of bcm43xx
and b43legacy. No
replacement will be needed for bcm43xx as it will not be in the kernel much
longer.
The effort required to maintain b43legacy should be minimal. For the past
several months, most of
what I have done is take b43 patches written by Michael Buesch and
dmatch_size'
> ohci-hcd.c:(.text+0xbffe5): undefined reference to `ssb_device_disable'
> [...]
>
> the reason was that this Kconfig combination was allowed:
>
> CONFIG_SSB=m
> CONFIG_USB_OHCI_HCD=y
> CONFIG_USB_OHCI_HCD_SSB=y
>
> the fix is to require a
On Monday 15 October 2007 12:53:44 Ingo Molnar wrote:
>
> * Al Viro <[EMAIL PROTECTED]> wrote:
>
> > On Sun, Oct 14, 2007 at 05:29:48AM +0200, Ingo Molnar wrote:
> > >
> > > FYI, the attached config fails to build on most recent -git with:
> > >
> > > In file included from drivers/usb/host/ohc
fixes
> the problem.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
> ---
>
> drivers/ssb/main.c | 11 +++
> 1 file changed, 3 insertions(+), 8 d
On Sunday 14 October 2007 05:29:48 Ingo Molnar wrote:
>
> FYI, the attached config fails to build on most recent -git with:
>
> In file included from drivers/usb/host/ohci-hcd.c:1038:
> drivers/usb/host/ohci-ssb.c:120: error: 'ohci_bus_suspend' undeclared here
> (not in a function)
> drivers/
On Saturday 13 October 2007 20:38:43 Geert Uytterhoeven wrote:
> On Sat, 13 Oct 2007, Larry Finger wrote:
> > Geert Uytterhoeven wrote:
> > > linux/drivers/net/wireless/b43/pio.h: In function 'b43_pio_write':
> > > linux/drivers/net/wireless/b43/pio.h:89: error: implicit declaration of
> > > funct
rivers/ssb/main.c: In function 'ssb_ssb_write32':
> linux/drivers/ssb/main.c:542: error: implicit declaration of function 'writel'
>
> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
> ---
> d
gt; linuxdrivers/net/wireless/b43/sysfs.c:147: error: implicit declaration of
> function 'mmiowb'
>
> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Cc: Larry Finger <[EMAIL PROTECTED]>
> ---
>
On Wednesday 12 September 2007 12:17:45 Paul Mundt wrote:
> On Wed, Sep 12, 2007 at 12:09:09PM +0200, Michael Buesch wrote:
> > On Wednesday 12 September 2007 04:11:00 Paul Mundt wrote:
> > > SSB uses a bool (SSB_PCMCIAHOST_POSSIBLE) to determine whether to
> > > build i
On Wednesday 12 September 2007 04:11:00 Paul Mundt wrote:
> SSB uses a bool (SSB_PCMCIAHOST_POSSIBLE) to determine whether to
> build in PCMCIA support or not, as the PCMCIA host code itself is
> also only a bool, make SSB_PCMCIAHOST_POSSIBLE depend on PCMCIA=y.
>
> Without this, SSB_PCMCIAHOST_PO
On Friday 07 September 2007, Johannes Berg wrote:
> On Thu, 2007-09-06 at 08:46 -0700, Paul E. McKenney wrote:
>
> > Looks good to me from an RCU viewpoint. I cannot claim familiarity with
> > this code. I therefore especially like the indications of where RTNL
> > is held and not!!!
>
> :)
>
On Wednesday 05 September 2007, Reyk Floeter wrote:
> I'm the author of the free hardware driver layer for wireless Atheros
> devices in OpenBSD, also known as "OpenHAL".
>
> I'm still trying to get an idea about the facts and the latest state
> of the incidence that violated the copyright of my c
On Wednesday 29 August 2007 21:33:43 Jon Smirl wrote:
> What if a patch spans both code that is pure GPL and code imported
> from BSD, how do you license it?
I think it's a valid assumption, if we say that the author
of the patch read the license header of a file and agreed with it.
So the patch i
On Wednesday 22 August 2007 18:33:58 Rafael J. Wysocki wrote:
> On Wednesday, 22 August 2007 11:06, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
> >
> > - git-ixgbe.patch got dropped - git-net.patch destroyed it
> >
> > - t
On Wednesday 15 August 2007 15:29:43 Arnd Bergmann wrote:
> On Wednesday 15 August 2007, Paul E. McKenney wrote:
>
> > ACCESS_ONCE() is indeed intended to be used when actually loading or
> > storing the variable. That said, I must admit that it is not clear to me
> > why you would want to add an
On Thursday 09 August 2007 16:24:57 Rafael J. Wysocki wrote:
> On Thursday, 9 August 2007 10:51, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc2/2.6.23-rc2-mm1/
> >
> > - Added new NFSD development tree as git-nfsd ("J. Bruce Fields"
> > <[
On Thursday 09 August 2007 02:15:33 Andi Kleen wrote:
> On Wed, Aug 08, 2007 at 05:08:44PM -0400, Chris Snook wrote:
> > Heiko Carstens wrote:
> > >On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote:
> > >>From: Heiko Carstens <[EMAIL PROTECTED]>
> > >>Date: Wed, 8 Aug 2007 11:33:00 +0200
On Thursday 02 August 2007, Geert Uytterhoeven wrote:
> On Thu, 2 Aug 2007, Michael Buesch wrote:
> > On Thursday 02 August 2007, Geert Uytterhoeven wrote:
> > > On Fri, 27 Jul 2007, Michael Buesch wrote:
> > > > The Sonics Silicon Backplane is a mini-bus used on
>
On Thursday 02 August 2007, Geert Uytterhoeven wrote:
> On Fri, 27 Jul 2007, Michael Buesch wrote:
> > The Sonics Silicon Backplane is a mini-bus used on
> > various Broadcom chips and embedded devices.
> > Devices using the SSB include b44, bcm43xx and various
> > Broa
eing selected. But appearantly it looks like this
> > doesn't matter at all if it gets selected from somewhere else.
> > So add an explicit depends on HAS_IOMEM to the Broadcom driver to
> > prevent selection on s390.
> >
> > Cc: "John W. Linville"
On Wednesday 01 August 2007, Andrew Morton wrote:
> On Sun, 29 Jul 2007 13:24:54 +0200 Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > The Sonics Silicon Backplane is a mini-bus used on
> > various Broadcom chips and embedded devices.
>
> Sigh.
>
> s390:
1 - 100 of 210 matches
Mail list logo
