On 5 Jul 2007, at 23:27, Rod Whitby wrote:
Alan Cox wrote:
Chipsets
ARTOP
No reports, but nobody appears to be using one
The NSLU2-Linux project (http://www.nslu2-linux.org) relies on the
pata-artop driver for the arm/ixp4xx-based Iomega NAS100d and D-Link
DSM-G600 NAS device
Richard Purdie wrote:
> Index: linux-2.6.21/lib/Kconfig
> ===
> --- linux-2.6.21.orig/lib/Kconfig 2007-06-04 12:19:37.0 +0100
> +++ linux-2.6.21/lib/Kconfig 2007-06-04 12:19:46.0 +0100
> @@ -71,6 +71,11 @@ config A
Andrew Morton wrote:
> Lots of git goodies there - I didn't actually receive the patch: the parts
> which move files around were communicated via git metadata, not diffs.
> Presumably there's a way to tell git to not do that.
>
> But probably it's best that this change be merged via git anyway. D
Satyam Sharma wrote:
> Ugh, I wish you had held on from this patch till the original thread
> discussing this reached some conclusion ... from Mark's response
> there it does seem PRESET_DICT is clearly an implementation
> (and not interface) detail -- which means to me that it must continue
> to l
27; public zlib
header include/linux/zlib.h.
Conditional compile of only inflate or deflate code is
preserved by this patch. With a bit of luck, this version
won't be whitespace-damaged. Grumble.
Signed-off-by: Michael-Luke Jones <[EMAIL PROTECTED]>
diff --git a/fs/jffs2/compr_zlib.c b/
27; public zlib header
include/linux/zlib.h. This move is documented in comments.
Conditional compile of only inflate or deflate code is
preserved by this patch.
Signed-off-by: Michael-Luke Jones <[EMAIL PROTECTED]>
diff --git a/fs/jffs2/compr_zlib.c b/fs/jffs2/compr_zlib.c
index 2b87fcc
ble
right now, unfortunately,
Michael-Luke Jones
[added David Whitehouse to cc]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the F
Rafael J. Wysocki wrote:
On Tuesday, 29 May 2007 08:55, Kay Sievers wrote:
The shiny userspace firmware loading causes problems since it exists,
every second box has problems with it, in all sorts of situations. If
people are still sold to the idea of userspace firmware loading, why
don't we kee
On 29 May 2007, at 11:41, Satyam Sharma wrote:
This is syntactically correct (and wouldn't produce any build errors),
but it's quite ... strange, still. Why would I even want to /build/
the
compress code if all I selected was the decompress option?
Apologies, you gave me the answer I was lo
On 28 May 2007, at 15:34, Nitin Gupta wrote:
diff --git a/lib/Kconfig b/lib/Kconfig
index 2e7ae6b..eb95eaa 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -64,6 +64,12 @@ config ZLIB_INFLATE
config ZLIB_DEFLATE
tristate
+config LZO1X_COMPRESS
+ tristate
+
+config LZO1X_DECOMPRESS
+
On 28 May 2007, at 18:11, Adrian Bunk wrote:
I have not seen any explanations:
- Why did the upstream author write the code that way?
Apparently due to his requirement for extreme portability. The
original code was designed to work on everything from 16-bit DOS
through CRAY supercomputers
of hotplug / uevents, there is no such documentation. Thus, what
kernelspace / userspace interactions actually are and what they
should be is unclear, leading to confusion over corner cases, such as
this one.
Michael-Luke Jones
-
To unsubscribe from this list: send the line "unsubscribe linux
On 28 May 2007, at 12:51, Kay Sievers wrote:
Either the whole idea of userspace firmware-loading should be
considered
as a problem impossible to do right because of its unsolvable side
effects. Or at least releasing loaded firmware should be the exception
for drivers which can be sure, that th
o this way...
Michael-Luke Jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
rtunity for a rework
of this API.
Michael-Luke Jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
? Not on the surface, but if the device loads root
over this device, it suddenly is.
This functionality should also be written into the firmware-class
(and this fact *is* acknowledged in the sparse documentation).
Michael-Luke Jones
-
To unsubscribe from this list: send the line "unsubs
On 28 May 2007, at 07:59, Nitin Gupta wrote:
If we get no perf. problems with this patch, then I beleive it is now
suitable to inclusion in mainline. Further cleanups and optimizations
can surely be done after that. It's still just ~500 LOC.
Before LZO code is sent to Linus, its selection in K
from userspace when it's ready.
Absolutely. I said this in an earlier email and suggested rejecting
this patchset on the grounds that it was another bodge covering over
a fundamentally broken area of the kernel :)
Kay
Michael-Luke Jones
-
To unsubscribe from this list: send the l
) is fail to share this information.
Michael-Luke Jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 28 May 2007, at 08:43, Rafael J. Wysocki wrote:
Seems, that's just the broken synchronous firmware loading interface
with the useless timeout handling. The nowait version of the same
loader
doesn't time out, and should not have that problem. The sync version
should be removed from the kern
ould be preferred, and preferably
one which allows firmware loading to *actually* occur once userspace
has actually turned up and registered a handler :)
Michael-Luke Jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL P
On 25 May 2007, at 11:42, Pavel Machek wrote:
What is the performance difference between safe and unsafe version?
On 24 May 2007, at 23:26, Richard Purdie wrote:
For my minilzo kernel patch, the safe version showed a 7.2%
performance
hit.
The conclusion seemed to be that we should drop the
On 25 May 2007, at 12:45, Nitin Gupta wrote:
Hi,
This is kernel port of LZO1X compressor and LZO1X decompressor (safe
version only).
Hey there,
It's looking better now. Just wondering if you might want to separate
out the Kconfig options for lzo compress / decompress so that it's
orthogo
On 24 May 2007, at 19:50, Andrew Morton wrote:
On Thu, 24 May 2007 18:15:17 +0100
Michael-Luke Jones <[EMAIL PROTECTED]> wrote:
Attached is a patch which may be desirable for -mm. It applies
directly to 2.6.22-rc2-mm1.
The patch removes the 'unsafe' LZO decompression functi
#x27; function should be used.
Comments / disagreement all welcome :)
Michael-Luke Jones
lzo-remove-unsafe-decompressor.patch
Description: Binary data
On 23 May 2007, at 15:21, Nitin Gupta wrote:
If somebody is up to including compression he must be having head
to use the right
decompress version depending on this scenario :-)
By that logic, experienced kernel dev Richard Purdie is not up to
using compression (?!)
To me, it looks like
On 23 May 2007, at 15:03, Nitin Gupta wrote:
Perhaps a rename is in order:
lzo1x_decompress() => lzo1x_decompress_unsafe()
lzo1x_decompress_safe => lzo1x_decompress()
Or perhaps make reiserfs use _safe() instead - I think Richard has
already submitted patch for same.
If someone's already mad
On 23 May 2007, at 12:39, Nitin Gupta wrote:
Hi Michael,
On 5/23/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote:
I understand that the 'safe' decompression code is 'somewhat slower'
and that decompressor performance is a key feature of this algorithm.
However
pert, so I may be off the mark with
this one. To me, at least, even if the answer is 'no, there isn't a
problem' that's still a valuable clarification :)
Thanks,
Michael-Luke Jones
[please cc me on replies as I am not subscribed to lkml]
-
To unsubscribe from this list: se
On 16 May 2007, at 10:41, Lennert Buytenhek wrote:
Making a driver work in both modes
of operation is generally not just an issue of adding a couple of
be32_to_cpu()s in the right places.
While this comment is technically correct, Christian's driver
achieves endian agnostic operation with onl
rking implementation LE implementation can be
viewed here:
http://www.hohnstaedt.de/ixp_npe/0.3.1/ixp4xx_npe_driver-0.3.1.diff
Search in this file for "swap the payload of the SKB" (it's in
mac_driver.c)
Michael-Luke Jones
-
To unsubscribe from this list: send the line "unsubsc
On 9 May 2007, at 15:22, David Acker wrote:
Big endian is the natural setup for the NPEs on this hardware
according to the intel documentation. Please don't stop this
driver from moving forward so that a few folks can run their
hardware in slow mode.
No-one is saying that this driver shou
On 8 May 2007, at 09:48, Alexey Zaytsev wrote:
I was always curious, why do people want to run ixp4xx in LE mode?
What
are the benefits that overweight the obvious performance degradation?
Debian.
http://www.debian.org/ports/arm/
Michael-Luke
-
To unsubscribe from this list: send the line
On 8 May 2007, at 09:26, Mikael Pettersson wrote:
On Tue, 8 May 2007 08:22:17 +0100, Michael-Luke Jones wrote:
AFAIK, it's a HW limitation of the IXP4xx NPEs, or
possibly Intel's microcode for them.
I run my IXP42x boxes big-endian and don't mind doing so.
/Mikael
fine CHAN_RX_BUF_CFG_WRITE 0x48
+#define CHAN_TX_BLK_CFG_WRITE 0x49
+#define CHAN_TX_BUF_ADDR_WRITE 0x4A
+#define CHAN_TX_BUF_SIZE_WRITE 0x4B
+#define CHAN_TSLOTSWITCH_ENABLE 0x4C
+#define CHAN_TSLOTSWITCH_DISABLE
On 8 May 2007, at 01:46, Krzysztof Halasa wrote:
Adds a driver for built-in IXP4xx hardware Queue Manager.
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
[snip]
diff --git a/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c b/arch/arm/mach-
ixp4xx/ixp4xx_qmgr.c
new file mode 100644
index 000..b9
On 8 May 2007, at 01:36, Krzysztof Halasa wrote:
Adds a driver for built-in IXP4xx Network Processor Engines.
This patch requires IXP4xx Queue Manager driver and the "fuses" patch.
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
[snip]
diff --git a/arch/arm/mach-ixp4xx/ixp4xx_npe.c b/ar
[Added Lennert Buytenhek to CC list]
Hey again,
Code placement:
Queue Manager & NPE code => arch/arm/mach-ixp4xx
WAN driver code => drivers/net/wan
Eth code => drivers/net/arm
Why would you want such placement?
Potential problems: header files would have to be moved to
include/asm-arm = heade
should still be exposed in arch/arm/mach-
ixp4xx/Kconfig
Michael-Luke Jones
PS: Please cc me on replies as I only subscribe to l-a-k.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at htt
But using 'fakeraid' (i.e. BIOS RAID) together with dmraid is
generally discouraged in favour of using the more stable and well
supported Linux Software RAID functionality.
Michael-Luke
On 24 Feb 2007, at 15:24, Bartlomiej Zolnierkiewicz wrote:
use device mapper and dmraid
http:/
NB: I'm not subscribed so please CC me in any reply! Thanks...
Updated bugzilla with x86 defconfig demonstrating similar breakage.
http://bugzilla.kernel.org/show_bug.cgi?id=8050
Both issues seem to demonstrate a problem with built-in NFS and
modular IPV6 together.
Michael-Luke Jones
Kernel Bugzilla bug created:
http://bugzilla.kernel.org/show_bug.cgi?id=8050
Michael-Luke Jones
On 21 Feb 2007, at 14:36, Michael-Luke Jones wrote:
Apologies for brain failure, below should read 2.6.21-rc1.
Everything else should be correct.
Michael-Luke Jones
On 21 Feb 2007, at 10:50, M.L
Apologies for brain failure, below should read 2.6.21-rc1.
Everything else should be correct.
Michael-Luke Jones
On 21 Feb 2007, at 10:50, M.L. Jones wrote:
NB: I'm not subscribed so please CC me in any reply! Thanks...
Hi there,
Just attempted a build of vanilla 2.6.20-rc1 and
43 matches
Mail list logo
