On Fri, Jan 4, 2013 at 1:39 PM, Chris Wilson wrote:
> Prevent a divide-by-zero by consistently treating an 'active' CRTC
> without a mode set as actually disabled.
> ---
Works fine here, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Fri, Jan 4, 2013 at 1:39 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
Prevent a divide-by-zero by consistently treating an 'active' CRTC
without a mode set as actually disabled.
---
Works fine here, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Fri, Jan 4, 2013 at 1:18 AM, Linus Torvalds
wrote:
> On Thu, Jan 3, 2013 at 3:12 PM, Alexey Zaytsev
> wrote:
>>
>> Chris: The patch does not seem to have any effect on the problem.
>>
>> Peter: I've attached the dmesgs, as well as the diff between the
>&g
On Fri, Jan 4, 2013 at 1:18 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Jan 3, 2013 at 3:12 PM, Alexey Zaytsev alexey.zayt...@gmail.com
wrote:
Chris: The patch does not seem to have any effect on the problem.
Peter: I've attached the dmesgs, as well as the diff between
On Mon, Feb 25, 2008 at 3:25 PM, Pekka J Enberg <[EMAIL PROTECTED]> wrote:
> On Mon, 25 Feb 2008, Michael Buesch wrote:
> > > Neither of which seem like acceptable solutions for a 2.6.23 -> 2.6.24
> > > _regression_. Or maybe I am just too naive to believe Linus' statement
> > > on not letting
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 this was possible, you manually changed the
> > > > module
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 this was possible, you manually changed the
module loading order, so that
On Mon, Feb 25, 2008 at 3:25 PM, Pekka J Enberg [EMAIL PROTECTED] wrote:
On Mon, 25 Feb 2008, Michael Buesch wrote:
Neither of which seem like acceptable solutions for a 2.6.23 - 2.6.24
_regression_. Or maybe I am just too naive to believe Linus' statement
on not letting the kernel
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, and there is no chance fixing it). The
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, and there is no chance fixing it). The problem is with enabling
On Sat, Feb 23, 2008 at 7:27 PM, 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 maintainers i've
> > ever seen
On Sat, Feb 23, 2008 at 7:20 PM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> 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 10064
ing to get git-send-patch to work
with the gmail smtp server, so the patches were went with
the thunderbird. If they end up being correpted, I've added
them as attachments.
-----
From: Alexey Zaytsev <[EMAIL PROTECTED]>
Date: Sat, 23 Feb 2008 12:59:26 +0300
Subject: [PATCH] Use a separa
t; ("[B44]: port to native ssb support") fix the regression?
> > >
>
>
> On Sat, 23 Feb 2008, Alexey Zaytsev wrote:
> > Compiling it right now.
> >
> > I'm sure it fixes the problem, but I don't feel like we should revert
> > it. I can't
> &g
On Sat, Feb 23, 2008 at 2:37 PM, Pekka Enberg <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 23, 2008 at 1:32 PM, Alexey Zaytsev
> <[EMAIL PROTECTED]> wrote:
> > The problem is not with enabling both b43 and bcm43xx (will, whis won't
> work
> > anyw
On Sat, Feb 23, 2008 at 2:24 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Pekka Enberg <[EMAIL PROTECTED]> wrote:
>
> > Agreed. Alexey, did you identify a specific git commit that caused the
> > regression? Can we just revert that from 2.6.24? Michael, even if
> > _you're_ planning to
On Sat, Feb 23, 2008 at 2:24 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
* Pekka Enberg [EMAIL PROTECTED] wrote:
Agreed. Alexey, did you identify a specific git commit that caused the
regression? Can we just revert that from 2.6.24? Michael, even if
_you're_ planning to remove bcm43xx we
On Sat, Feb 23, 2008 at 2:37 PM, Pekka Enberg [EMAIL PROTECTED] wrote:
On Sat, Feb 23, 2008 at 1:32 PM, Alexey Zaytsev
[EMAIL PROTECTED] 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
?
On Sat, 23 Feb 2008, Alexey Zaytsev wrote:
Compiling it right now.
I'm sure it fixes the problem, but I don't feel like we should revert
it. I can't
be sure it won't cause any other problems, and anyway, this does not look
right a solution. Any other driver (rightfully) requiring
-send-patch to work
with the gmail smtp server, so the patches were went with
the thunderbird. If they end up being correpted, I've added
them as attachments.
-
From: Alexey Zaytsev [EMAIL PROTECTED]
Date: Sat, 23 Feb 2008 12:59:26 +0300
Subject: [PATCH] Use a separate config option
On Sat, Feb 23, 2008 at 7:20 PM, Michael Buesch [EMAIL PROTECTED] wrote:
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
On Sat, Feb 23, 2008 at 7:27 PM, 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 maintainers i've
ever seen on lkml:
On Sat, Feb 23, 2008 at 1:12 AM, Greg KH <[EMAIL PROTECTED]> wrote:
>
> On Fri, Feb 22, 2008 at 11:38:34PM +0300, Alexey Zaytsev wrote:
> > On Fri, Feb 22, 2008 at 11:12 PM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > > On Friday 22 February 2
On Fri, Feb 22, 2008 at 11:12 PM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> 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_
[replying from my non-work account]
On Fri, Feb 22, 2008 at 8:48 PM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> 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 the
Michael Buesch wrote:
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
me pci ids.
Now we enable the birdge only if the b43{legacy}
drivers are selected.
Signed-off-by: Alexey Zaytsev <[EMAIL PROTECTED]>
---
drivers/net/wireless/b43/Kconfig |4
drivers/net/wireless/b43legacy/Kconfig |4
drivers/net/wireless/bcm43xx/Kconfig |
.
Now we enable the birdge only if the b43{legacy}
drivers are selected.
Signed-off-by: Alexey Zaytsev [EMAIL PROTECTED]
---
drivers/net/wireless/b43/Kconfig |4
drivers/net/wireless/b43legacy/Kconfig |4
drivers/net/wireless/bcm43xx/Kconfig |2 +-
drivers/ssb
Michael Buesch wrote:
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
On Fri, Feb 22, 2008 at 11:12 PM, Michael Buesch [EMAIL PROTECTED] wrote:
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
[replying from my non-work account]
On Fri, Feb 22, 2008 at 8:48 PM, Michael Buesch [EMAIL PROTECTED] wrote:
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
On Sat, Feb 23, 2008 at 1:12 AM, Greg KH [EMAIL PROTECTED] wrote:
On Fri, Feb 22, 2008 at 11:38:34PM +0300, Alexey Zaytsev wrote:
On Fri, Feb 22, 2008 at 11:12 PM, Michael Buesch [EMAIL PROTECTED] wrote:
On Friday 22 February 2008 21:06:00 Alexey Zaytsev wrote:
It is not my
On 9/17/07, Sergey Dolgov <[EMAIL PROTECTED]> wrote:
> On 9/17/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
>
> [...]
> > BTW, this only happens when using libata of course. The
> > old CONFIG_IDE stuff works fine every time.
> > >>> This maybe one of libata weirdness (I really don't get it
On 9/17/07, Sergey Dolgov [EMAIL PROTECTED] wrote:
On 9/17/07, Tejun Heo [EMAIL PROTECTED] wrote:
[...]
BTW, this only happens when using libata of course. The
old CONFIG_IDE stuff works fine every time.
This maybe one of libata weirdness (I really don't get it why some
hardware
On 5/8/07, Lennert Buytenhek <[EMAIL PROTECTED]> wrote:
...
As with Christian's driver, I don't know whether an SRAM allocator
makes much sense. We can just set up a static allocation map for the
in-tree drivers and leave out the allocator altogether. I.e. I don't
think it's worth the
On 5/8/07, Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:
Michael Jones wrote:
>> +#ifndef __ARMEB__
>> +#warning Little endian mode not supported
>> +#endif
>
> Personally I'm less fussed about WAN / LE support. Anyone with any
> sense will run ixp4xx boards doing such a specialised network
>
On 5/8/07, Tomasz Chmielewski [EMAIL PROTECTED] wrote:
Michael Jones wrote:
+#ifndef __ARMEB__
+#warning Little endian mode not supported
+#endif
Personally I'm less fussed about WAN / LE support. Anyone with any
sense will run ixp4xx boards doing such a specialised network
operation as
On 5/8/07, Lennert Buytenhek [EMAIL PROTECTED] wrote:
...
As with Christian's driver, I don't know whether an SRAM allocator
makes much sense. We can just set up a static allocation map for the
in-tree drivers and leave out the allocator altogether. I.e. I don't
think it's worth the complexity
Hello, Krzysztof.
On 5/7/07, Krzysztof Halasa <[EMAIL PROTECTED]> wrote:
...
+IXP4XX_FUSE_RSA | \
+IXP4XX_FUSE_XSCALE_MAX_FREQ)
+
#ifndef __ASSEMBLY__
+static inline u32 ixp4xx_read_fuses(void)
+{
+
Hello, Krzysztof.
On 5/7/07, Krzysztof Halasa [EMAIL PROTECTED] wrote:
...
+IXP4XX_FUSE_RSA | \
+IXP4XX_FUSE_XSCALE_MAX_FREQ)
+
#ifndef __ASSEMBLY__
+static inline u32 ixp4xx_read_fuses(void)
+{
+
On 2/27/07, Kyle McMartin <[EMAIL PROTECTED]> wrote:
On Tue, Feb 27, 2007 at 08:20:21AM -0500, Kyle McMartin wrote:
> PCI is always little endian, unless it's not. In which case you're probably
PCI is always LE, but the host may be different. If you read some data
from a PCI device
on a LE
On 2/26/07, Kyle McMartin <[EMAIL PROTECTED]> wrote:
On Mon, Feb 26, 2007 at 06:36:05PM +0300, Alexey Zaytsev wrote:
> Hello.
>
> May I ask you, guys, if ioread32 and his friends should treat the data
> as host-endian or bus-endian? E.g, should the data read from PCI on a
On 2/26/07, Kyle McMartin [EMAIL PROTECTED] wrote:
On Mon, Feb 26, 2007 at 06:36:05PM +0300, Alexey Zaytsev wrote:
Hello.
May I ask you, guys, if ioread32 and his friends should treat the data
as host-endian or bus-endian? E.g, should the data read from PCI on a
big-endian host be byte
On 2/27/07, Kyle McMartin [EMAIL PROTECTED] wrote:
On Tue, Feb 27, 2007 at 08:20:21AM -0500, Kyle McMartin wrote:
PCI is always little endian, unless it's not. In which case you're probably
PCI is always LE, but the host may be different. If you read some data
from a PCI device
on a LE host,
Hello.
May I ask you, guys, if ioread32 and his friends should treat the data
as host-endian or bus-endian? E.g, should the data read from PCI on a
big-endian host be byte swapped or not?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Hello.
May I ask you, guys, if ioread32 and his friends should treat the data
as host-endian or bus-endian? E.g, should the data read from PCI on a
big-endian host be byte swapped or not?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
46 matches
Mail list logo
