Re: Libata PATA status (pata_artop)
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 devices (both of which are supported in recent mainline kernels). Latest kernels (2.6.22-rc5 is the latest we've tested) have no reported problems with pata-artop. We have a handful of people (including myself) who we know are using 2.6.22-rc5 on those devices and are booting from the internal drive using the pata-artop driver. Though we have no reported problems, we are carrying a local patch to the pata_artop driver: http://trac.nslu2-linux.org/kernel/browser/trunk/patches/2.6.22/15- nas100d-pata-artop-single-port.patch This used to be because of a long delay when probing the non-existent second ATA port on these embedded ARM devices, but the comment in the patch has since been updated suggesting some negative interaction with USB (??). I don't have this machine so can't comment further on this issue, M-L - 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/
Re: Libata PATA status (pata_artop)
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 devices (both of which are supported in recent mainline kernels). Latest kernels (2.6.22-rc5 is the latest we've tested) have no reported problems with pata-artop. We have a handful of people (including myself) who we know are using 2.6.22-rc5 on those devices and are booting from the internal drive using the pata-artop driver. Though we have no reported problems, we are carrying a local patch to the pata_artop driver: http://trac.nslu2-linux.org/kernel/browser/trunk/patches/2.6.22/15- nas100d-pata-artop-single-port.patch This used to be because of a long delay when probing the non-existent second ATA port on these embedded ARM devices, but the comment in the patch has since been updated suggesting some negative interaction with USB (??). I don't have this machine so can't comment further on this issue, M-L - 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/
Re: [PATCH -mm 1/5] Add LZO1X compression support to the kernel
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 AUDIT_GENERIC > depends on AUDIT && !AUDIT_ARCH > default y > > +config LZO > + tristate "LZO compressor/decompressor" > + help > + minilzo implementation in kernelspace. > + > # > # compression support is select'ed if needed > # Can this support option be hidden please, with decompression and compression support Kconfig options separated out to support minimal compilation of just the decompressor for read-only filesystems. Michael-Luke - 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/
Re: [PATCH -mm 1/5] Add LZO1X compression support to the kernel
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 AUDIT_GENERIC depends on AUDIT !AUDIT_ARCH default y +config LZO + tristate LZO compressor/decompressor + help + minilzo implementation in kernelspace. + # # compression support is select'ed if needed # Can this support option be hidden please, with decompression and compression support Kconfig options separated out to support minimal compilation of just the decompressor for read-only filesystems. Michael-Luke - 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/
Re: [-mm] Move zlib compression library to common directory [TAKE TWO]
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. David, > are you interested in handling it? Update: totally ignore this patch. Even using git-apply something gets confused and git loses the meaning of the renames, turning them into file additions and deletions. A better version will no doubt come along. In the mean time, it looks like I need to improve my git-foo skills... M-L - 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/
Re: [-mm] Move zlib compression library to common directory [TAKE TWO]
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 live in zutil.h (the private header) ... but then, this change is > clearly not so critical either, so it doesn't matter much, I guess. Satyam: Sorry about this, I wrote this before the conversation on this point started, expecting the discussion to happen here. My hope was to see if this minimal change to export PRESET_DICT was acceptable (if not ideal). Given that practically all of the implementation details are currently exported, it's probably an improvement to only export one :) Andrew: The main reason for this change is to allow a private header to be moved from include/linux/ to this private folder. It's already been used apparently inappropriately by JFFS2 compression code. Minimal code changes, lots of file moving (as I'm sure you can see)... I managed to get the patch to apply to a fresh tree using 'git apply', which may well mean that I didn't understand your comment that "the parts which move files around were communicated via git metadata, not diffs". Given that, since I wrote this patch, no-one has actually said anything positive about it, there's probably not much point picking it up until people have worked out exactly what to do with JFFS2's inappropriate use of the public-private zutil.h header. At least it's just JFFS2 :) > [ Added zlib authors Mark Adler and Jean-Loup Gailly on this > thread too. ] Thanks, I should have CCed the authors/maintainers originally. > Satyam Michael-Luke (PS: The stern warning is also present in the other private zlib header files.) - 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/
Re: [-mm] Move zlib compression library to common directory [TAKE TWO]
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. David, are you interested in handling it? Update: totally ignore this patch. Even using git-apply something gets confused and git loses the meaning of the renames, turning them into file additions and deletions. A better version will no doubt come along. In the mean time, it looks like I need to improve my git-foo skills... M-L - 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/
Re: [-mm] Move zlib compression library to common directory [TAKE TWO]
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 live in zutil.h (the private header) ... but then, this change is clearly not so critical either, so it doesn't matter much, I guess. Satyam: Sorry about this, I wrote this before the conversation on this point started, expecting the discussion to happen here. My hope was to see if this minimal change to export PRESET_DICT was acceptable (if not ideal). Given that practically all of the implementation details are currently exported, it's probably an improvement to only export one :) Andrew: The main reason for this change is to allow a private header to be moved from include/linux/ to this private folder. It's already been used apparently inappropriately by JFFS2 compression code. Minimal code changes, lots of file moving (as I'm sure you can see)... I managed to get the patch to apply to a fresh tree using 'git apply', which may well mean that I didn't understand your comment that the parts which move files around were communicated via git metadata, not diffs. Given that, since I wrote this patch, no-one has actually said anything positive about it, there's probably not much point picking it up until people have worked out exactly what to do with JFFS2's inappropriate use of the public-private zutil.h header. At least it's just JFFS2 :) [ Added zlib authors Mark Adler and Jean-Loup Gailly on this thread too. ] Thanks, I should have CCed the authors/maintainers originally. Satyam Michael-Luke (PS: The stern warning is also present in the other private zlib header files.) - 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/
[-mm] Move zlib compression library to common directory [TAKE TWO]
This patch moves the zlib compression and decompression code to a common directory. The zutil.h header, which is not meant to be public, is moved from include/linux/ to lib/zlib/. In addition, the PRESET_DICT definition from zutil.h, used by fs/jffs2/compr_zlib.c is moved to the 'true' 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/fs/jffs2/compr_zlib.c index 2b87fcc..e2cc6c7 100644 --- a/fs/jffs2/compr_zlib.c +++ b/fs/jffs2/compr_zlib.c @@ -16,7 +16,6 @@ #include #include #include -#include #include "nodelist.h" #include "compr.h" diff --git a/include/linux/zlib.h b/include/linux/zlib.h index 9e3192a..e9d32c5 100644 --- a/include/linux/zlib.h +++ b/include/linux/zlib.h @@ -177,6 +177,9 @@ typedef z_stream *z_streamp; #define Z_DEFLATED 8 /* The deflate compression method (the only one supported in this version) */ +#define PRESET_DICT 0x20 /* preset dictionary flag in zlib header */ +/* Required by fs/jffs2/compr_zlib.c */ + /* basic functions */ extern int zlib_deflate_workspacesize (void); diff --git a/lib/Makefile b/lib/Makefile index c8c8e20..42c3903 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -46,8 +46,8 @@ obj-$(CONFIG_CRC32) += crc32.o obj-$(CONFIG_LIBCRC32C)+= libcrc32c.o obj-$(CONFIG_GENERIC_ALLOCATOR) += genalloc.o -obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate/ -obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate/ +obj-$(CONFIG_ZLIB_INFLATE) += zlib/ +obj-$(CONFIG_ZLIB_DEFLATE) += zlib/ obj-$(CONFIG_REED_SOLOMON) += reed_solomon/ obj-$(CONFIG_TEXTSEARCH) += textsearch.o diff --git a/lib/zlib_inflate/Makefile b/lib/zlib/Makefile similarity index 71% rename from lib/zlib_inflate/Makefile rename to lib/zlib/Makefile index bf06548..528d903 100644 --- a/lib/zlib_inflate/Makefile +++ b/lib/zlib/Makefile @@ -2,8 +2,8 @@ # This is a modified version of zlib, which does all memory # allocation ahead of time. # -# This is only the decompression, see zlib_deflate for the -# the compression +# The compression (deflate) and decompression (inflate) code +# is present in this folder. # # Decompression needs to be serialized for each memory # allocation. @@ -17,3 +17,7 @@ obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate.o zlib_inflate-objs := inffast.o inflate.o \ inftrees.o inflate_syms.o + +obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate.o + +zlib_deflate-objs := deflate.o deftree.o deflate_syms.o diff --git a/lib/zlib_deflate/deflate.c b/lib/zlib/deflate.c similarity index 100% rename from lib/zlib_deflate/deflate.c rename to lib/zlib/deflate.c index c3e4a2b..1137780 100644 --- a/lib/zlib_deflate/deflate.c +++ b/lib/zlib/deflate.c @@ -49,10 +49,9 @@ */ #include -#include +#include "zutil.h" #include "defutil.h" - /* === * Function prototypes. */ diff --git a/lib/zlib_deflate/deflate_syms.c b/lib/zlib/deflate_syms.c similarity index 100% rename from lib/zlib_deflate/deflate_syms.c rename to lib/zlib/deflate_syms.c diff --git a/lib/zlib_deflate/deftree.c b/lib/zlib/deftree.c similarity index 100% rename from lib/zlib_deflate/deftree.c rename to lib/zlib/deftree.c index ddf3482..d5ce87d 100644 --- a/lib/zlib_deflate/deftree.c +++ b/lib/zlib/deftree.c @@ -34,7 +34,7 @@ /* #include "deflate.h" */ -#include +#include "zutil.h" #include "defutil.h" #ifdef DEBUG_ZLIB diff --git a/lib/zlib_deflate/defutil.h b/lib/zlib/defutil.h similarity index 100% rename from lib/zlib_deflate/defutil.h rename to lib/zlib/defutil.h diff --git a/lib/zlib_inflate/inffast.c b/lib/zlib/inffast.c similarity index 100% rename from lib/zlib_inflate/inffast.c rename to lib/zlib/inffast.c index d84560c..50d3de1 100644 --- a/lib/zlib_inflate/inffast.c +++ b/lib/zlib/inffast.c @@ -3,7 +3,7 @@ * For conditions of distribution and use, see copyright notice in zlib.h */ -#include +#include "zutil.h" #include "inftrees.h" #include "inflate.h" #include "inffast.h" diff --git a/lib/zlib_inflate/inffast.h b/lib/zlib/inffast.h similarity index 100% rename from lib/zlib_inflate/inffast.h rename to lib/zlib/inffast.h diff --git a/lib/zlib_inflate/inffixed.h b/lib/zlib/inffixed.h similarity index 100% rename from lib/zlib_inflate/inffixed.h rename to lib/zlib/inffixed.h diff --git a/lib/zlib_inflate/inflate.c b/lib/zlib/inflate.c similarity index 100% rename from lib/zlib_inflate/inflate.c rename to lib/zlib/inflate.c index 7e1e311..ba58871 100644 --- a/lib/zlib_inflate/inflate.c +++ b/lib/zlib/inflate.c @@ -9,7 +9,7 @@ * */ -#include +#include "zutil.h" #include "inftrees.h" #include "inf
[-mm] Move zlib compression library to common directory
This patch moves the zlib compression and decompression code to a common directory. The zutil.h header, which is not meant to be public, is moved from include/linux/ to lib/zlib/. In addition, the PRESET_DICT definition from zutil.h, used by fs/jffs2/compr_zlib.c is moved to the 'true' 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..e2cc6c7 100644 --- a/fs/jffs2/compr_zlib.c +++ b/fs/jffs2/compr_zlib.c @@ -16,7 +16,6 @@ #include #include #include -#include #include "nodelist.h" #include "compr.h" diff --git a/include/linux/zlib.h b/include/linux/zlib.h index 9e3192a..e9d32c5 100644 --- a/include/linux/zlib.h +++ b/include/linux/zlib.h @@ -177,6 +177,9 @@ typedef z_stream *z_streamp; #define Z_DEFLATED 8 /* The deflate compression method (the only one supported in this version) */ +#define PRESET_DICT 0x20 /* preset dictionary flag in zlib header */ +/* Required by fs/jffs2/compr_zlib.c */ + /* basic functions */ extern int zlib_deflate_workspacesize (void); diff --git a/lib/Makefile b/lib/Makefile index c8c8e20..42c3903 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -46,8 +46,8 @@ obj-$(CONFIG_CRC32) += crc32.o obj-$(CONFIG_LIBCRC32C)+= libcrc32c.o obj-$(CONFIG_GENERIC_ALLOCATOR) += genalloc.o -obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate/ -obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate/ +obj-$(CONFIG_ZLIB_INFLATE) += zlib/ +obj-$(CONFIG_ZLIB_DEFLATE) += zlib/ obj-$(CONFIG_REED_SOLOMON) += reed_solomon/ obj-$(CONFIG_TEXTSEARCH) += textsearch.o diff --git a/lib/zlib_inflate/Makefile b/lib/zlib/Makefile similarity index 71% rename from lib/zlib_inflate/Makefile rename to lib/zlib/Makefile index bf06548..528d903 100644 --- a/lib/zlib_inflate/Makefile +++ b/lib/zlib/Makefile @@ -2,8 +2,8 @@ # This is a modified version of zlib, which does all memory # allocation ahead of time. # -# This is only the decompression, see zlib_deflate for the -# the compression +# The compression (deflate) and decompression (inflate) code +# is present in this folder. # # Decompression needs to be serialized for each memory # allocation. @@ -17,3 +17,7 @@ obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate.o zlib_inflate-objs := inffast.o inflate.o \ inftrees.o inflate_syms.o + +obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate.o + +zlib_deflate-objs := deflate.o deftree.o deflate_syms.o diff --git a/lib/zlib_deflate/deflate.c b/lib/zlib/deflate.c similarity index 100% rename from lib/zlib_deflate/deflate.c rename to lib/zlib/deflate.c index c3e4a2b..1137780 100644 --- a/lib/zlib_deflate/deflate.c +++ b/lib/zlib/deflate.c @@ -49,10 +49,9 @@ */ #include -#include +#include "zutil.h" #include "defutil.h" - /* === * Function prototypes. */ diff --git a/lib/zlib_deflate/deflate_syms.c b/lib/zlib/deflate_syms.c similarity index 100% rename from lib/zlib_deflate/deflate_syms.c rename to lib/zlib/deflate_syms.c diff --git a/lib/zlib_deflate/deftree.c b/lib/zlib/deftree.c similarity index 100% rename from lib/zlib_deflate/deftree.c rename to lib/zlib/deftree.c index ddf3482..d5ce87d 100644 --- a/lib/zlib_deflate/deftree.c +++ b/lib/zlib/deftree.c @@ -34,7 +34,7 @@ /* #include "deflate.h" */ -#include +#include "zutil.h" #include "defutil.h" #ifdef DEBUG_ZLIB diff --git a/lib/zlib_deflate/defutil.h b/lib/zlib/defutil.h similarity index 100% rename from lib/zlib_deflate/defutil.h rename to lib/zlib/defutil.h diff --git a/lib/zlib_inflate/inffast.c b/lib/zlib/inffast.c similarity index 100% rename from lib/zlib_inflate/inffast.c rename to lib/zlib/inffast.c index d84560c..50d3de1 100644 --- a/lib/zlib_inflate/inffast.c +++ b/lib/zlib/inffast.c @@ -3,7 +3,7 @@ * For conditions of distribution and use, see copyright notice in zlib.h */ -#include +#include "zutil.h" #include "inftrees.h" #include "inflate.h" #include "inffast.h" diff --git a/lib/zlib_inflate/inffast.h b/lib/zlib/inffast.h similarity index 100% rename from lib/zlib_inflate/inffast.h rename to lib/zlib/inffast.h diff --git a/lib/zlib_inflate/inffixed.h b/lib/zlib/inffixed.h similarity index 100% rename from lib/zlib_inflate/inffixed.h rename to lib/zlib/inffixed.h diff --git a/lib/zlib_inflate/inflate.c b/lib/zlib/inflate.c similarity index 100% rename from lib/zlib_inflate/inflate.c rename to lib/zlib/inflate.c index 7e1e311..ba58871 100644 --- a/lib/zlib_inflate/inflate.c +++ b/lib/zlib/inflate.c @@ -9,7 +9,7 @@ * */ -#include +#include "zutil.h" #include "inftrees.h" #include "inflate.h" #include "inffast.h&
JFFS2 using 'private' zlib header (was [RFC] LZO de/compression support - take 6)
On 29 May 2007, at 12:27, Satyam Sharma wrote: Right, actually, zlib could be switched over to [using a common directory]. Because zlib_deflate/ and zlib_inflate/ too share a private header zutil.h which has unfortunately been stuck into include/linux/ with a big /* WARNING: this file should *not* be used by applications. */ comment ... Well, unfortunately zutil.h is currently being used in-kernel by fs/ jffs2/compr_zlib.c despite the "WARNING: this file should *not* be used by applications" notice. So moving this header to a truly private location isn't possible 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 FAQ at http://www.tux.org/lkml/
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
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 keep the data in the driver, instead of immediately discarding it after the first upload? Not to waste a few hundred kilobytes? That doesn't sound like a convincing deal, after all the years people try to work around the issues it causes. Agreed. Rafael Rather than most drivers being told to make this step, can this be added to the firmware_class such that firmware objects are cached in RAM and subsequent calls to request_firmware() don't have to query userspace. This seems the least intrusive solution to this problem. Thanks, Michael-Luke - 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/
Re: Makefile question (was [RFC] LZO de/compression support - take 6)
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 looking for (make is 'intelligent' enough not to build the same file twice in this situation...) but I think you may have missed the makefile in the lzo1x directory: diff --git a/lib/lzo1x/Makefile b/lib/lzo1x/Makefile new file mode 100644 index 000..7b56a4d --- /dev/null +++ b/lib/lzo1x/Makefile @@ -0,0 +1,2 @@ +obj-$(CONFIG_LZO1X_COMPRESS) += lzo1x_compress.o +obj-$(CONFIG_LZO1X_DECOMPRESS) += lzo1x_decompress.o Thus, the Kconfig options for compress/decompress won't be simply 'dummy' options... Given the shared private header between the compress and decompress code, I don't think there is any need to separate the code into two directories a la the zlib code. Sorry for noise, Michael-Luke - 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/
Makefile question (was [RFC] LZO de/compression support - take 6)
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 + tristate + # # Generic allocator support is selected if needed # diff --git a/lib/Makefile b/lib/Makefile index c8c8e20..448ae37 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -49,6 +49,8 @@ obj-$(CONFIG_GENERIC_ALLOCATOR) += genalloc.o obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate/ obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate/ obj-$(CONFIG_REED_SOLOMON) += reed_solomon/ +obj-$(CONFIG_LZO1X_COMPRESS) += lzo1x/ +obj-$(CONFIG_LZO1X_DECOMPRESS) += lzo1x/ obj-$(CONFIG_TEXTSEARCH) += textsearch.o obj-$(CONFIG_TEXTSEARCH_KMP) += ts_kmp.o Hey there, Is this syntax OK for Makefile use? I'm only asking out of personal ignorance and because I'd use: Kconfig: config LZO1X_COMPRESS select LZO1X tristate config LZO1X_DECOMPRESS select LZO1X tristate config LZO1X tristate (or boolean??) Makefile: obj-$(CONFIG_LZO1X) += lzo1x/ Thanks, Michael-Luke - 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/
Re: [RFC] LZO de/compression support - take 6
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 through Windows, Unices and Linux. The author has stated on the thread that it's a good idea to remove unnecessary ifdefs when porting the code into the kernel, given that the portability requirements are obviously no longer needed. Michael-Luke - 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/
Re: [RFC] LZO de/compression support - take 6
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 through Windows, Unices and Linux. The author has stated on the thread that it's a good idea to remove unnecessary ifdefs when porting the code into the kernel, given that the portability requirements are obviously no longer needed. Michael-Luke - 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/
Makefile question (was [RFC] LZO de/compression support - take 6)
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 + tristate + # # Generic allocator support is selected if needed # diff --git a/lib/Makefile b/lib/Makefile index c8c8e20..448ae37 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -49,6 +49,8 @@ obj-$(CONFIG_GENERIC_ALLOCATOR) += genalloc.o obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate/ obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate/ obj-$(CONFIG_REED_SOLOMON) += reed_solomon/ +obj-$(CONFIG_LZO1X_COMPRESS) += lzo1x/ +obj-$(CONFIG_LZO1X_DECOMPRESS) += lzo1x/ obj-$(CONFIG_TEXTSEARCH) += textsearch.o obj-$(CONFIG_TEXTSEARCH_KMP) += ts_kmp.o Hey there, Is this syntax OK for Makefile use? I'm only asking out of personal ignorance and because I'd use: Kconfig: config LZO1X_COMPRESS select LZO1X tristate config LZO1X_DECOMPRESS select LZO1X tristate config LZO1X tristate (or boolean??) Makefile: obj-$(CONFIG_LZO1X) += lzo1x/ Thanks, Michael-Luke - 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/
Re: Makefile question (was [RFC] LZO de/compression support - take 6)
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 looking for (make is 'intelligent' enough not to build the same file twice in this situation...) but I think you may have missed the makefile in the lzo1x directory: diff --git a/lib/lzo1x/Makefile b/lib/lzo1x/Makefile new file mode 100644 index 000..7b56a4d --- /dev/null +++ b/lib/lzo1x/Makefile @@ -0,0 +1,2 @@ +obj-$(CONFIG_LZO1X_COMPRESS) += lzo1x_compress.o +obj-$(CONFIG_LZO1X_DECOMPRESS) += lzo1x_decompress.o Thus, the Kconfig options for compress/decompress won't be simply 'dummy' options... Given the shared private header between the compress and decompress code, I don't think there is any need to separate the code into two directories a la the zlib code. Sorry for noise, Michael-Luke - 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/
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
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 keep the data in the driver, instead of immediately discarding it after the first upload? Not to waste a few hundred kilobytes? That doesn't sound like a convincing deal, after all the years people try to work around the issues it causes. Agreed. Rafael Rather than most drivers being told to make this step, can this be added to the firmware_class such that firmware objects are cached in RAM and subsequent calls to request_firmware() don't have to query userspace. This seems the least intrusive solution to this problem. Thanks, Michael-Luke - 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/
JFFS2 using 'private' zlib header (was [RFC] LZO de/compression support - take 6)
On 29 May 2007, at 12:27, Satyam Sharma wrote: Right, actually, zlib could be switched over to [using a common directory]. Because zlib_deflate/ and zlib_inflate/ too share a private header zutil.h which has unfortunately been stuck into include/linux/ with a big /* WARNING: this file should *not* be used by applications. */ comment ... Well, unfortunately zutil.h is currently being used in-kernel by fs/ jffs2/compr_zlib.c despite the WARNING: this file should *not* be used by applications notice. So moving this header to a truly private location isn't possible 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 FAQ at http://www.tux.org/lkml/
[-mm] Move zlib compression library to common directory
This patch moves the zlib compression and decompression code to a common directory. The zutil.h header, which is not meant to be public, is moved from include/linux/ to lib/zlib/. In addition, the PRESET_DICT definition from zutil.h, used by fs/jffs2/compr_zlib.c is moved to the 'true' 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..e2cc6c7 100644 --- a/fs/jffs2/compr_zlib.c +++ b/fs/jffs2/compr_zlib.c @@ -16,7 +16,6 @@ #include linux/kernel.h #include linux/slab.h #include linux/zlib.h -#include linux/zutil.h #include nodelist.h #include compr.h diff --git a/include/linux/zlib.h b/include/linux/zlib.h index 9e3192a..e9d32c5 100644 --- a/include/linux/zlib.h +++ b/include/linux/zlib.h @@ -177,6 +177,9 @@ typedef z_stream *z_streamp; #define Z_DEFLATED 8 /* The deflate compression method (the only one supported in this version) */ +#define PRESET_DICT 0x20 /* preset dictionary flag in zlib header */ +/* Required by fs/jffs2/compr_zlib.c */ + /* basic functions */ extern int zlib_deflate_workspacesize (void); diff --git a/lib/Makefile b/lib/Makefile index c8c8e20..42c3903 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -46,8 +46,8 @@ obj-$(CONFIG_CRC32) += crc32.o obj-$(CONFIG_LIBCRC32C)+= libcrc32c.o obj-$(CONFIG_GENERIC_ALLOCATOR) += genalloc.o -obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate/ -obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate/ +obj-$(CONFIG_ZLIB_INFLATE) += zlib/ +obj-$(CONFIG_ZLIB_DEFLATE) += zlib/ obj-$(CONFIG_REED_SOLOMON) += reed_solomon/ obj-$(CONFIG_TEXTSEARCH) += textsearch.o diff --git a/lib/zlib_inflate/Makefile b/lib/zlib/Makefile similarity index 71% rename from lib/zlib_inflate/Makefile rename to lib/zlib/Makefile index bf06548..528d903 100644 --- a/lib/zlib_inflate/Makefile +++ b/lib/zlib/Makefile @@ -2,8 +2,8 @@ # This is a modified version of zlib, which does all memory # allocation ahead of time. # -# This is only the decompression, see zlib_deflate for the -# the compression +# The compression (deflate) and decompression (inflate) code +# is present in this folder. # # Decompression needs to be serialized for each memory # allocation. @@ -17,3 +17,7 @@ obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate.o zlib_inflate-objs := inffast.o inflate.o \ inftrees.o inflate_syms.o + +obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate.o + +zlib_deflate-objs := deflate.o deftree.o deflate_syms.o diff --git a/lib/zlib_deflate/deflate.c b/lib/zlib/deflate.c similarity index 100% rename from lib/zlib_deflate/deflate.c rename to lib/zlib/deflate.c index c3e4a2b..1137780 100644 --- a/lib/zlib_deflate/deflate.c +++ b/lib/zlib/deflate.c @@ -49,10 +49,9 @@ */ #include linux/module.h -#include linux/zutil.h +#include zutil.h #include defutil.h - /* === * Function prototypes. */ diff --git a/lib/zlib_deflate/deflate_syms.c b/lib/zlib/deflate_syms.c similarity index 100% rename from lib/zlib_deflate/deflate_syms.c rename to lib/zlib/deflate_syms.c diff --git a/lib/zlib_deflate/deftree.c b/lib/zlib/deftree.c similarity index 100% rename from lib/zlib_deflate/deftree.c rename to lib/zlib/deftree.c index ddf3482..d5ce87d 100644 --- a/lib/zlib_deflate/deftree.c +++ b/lib/zlib/deftree.c @@ -34,7 +34,7 @@ /* #include deflate.h */ -#include linux/zutil.h +#include zutil.h #include defutil.h #ifdef DEBUG_ZLIB diff --git a/lib/zlib_deflate/defutil.h b/lib/zlib/defutil.h similarity index 100% rename from lib/zlib_deflate/defutil.h rename to lib/zlib/defutil.h diff --git a/lib/zlib_inflate/inffast.c b/lib/zlib/inffast.c similarity index 100% rename from lib/zlib_inflate/inffast.c rename to lib/zlib/inffast.c index d84560c..50d3de1 100644 --- a/lib/zlib_inflate/inffast.c +++ b/lib/zlib/inffast.c @@ -3,7 +3,7 @@ * For conditions of distribution and use, see copyright notice in zlib.h */ -#include linux/zutil.h +#include zutil.h #include inftrees.h #include inflate.h #include inffast.h diff --git a/lib/zlib_inflate/inffast.h b/lib/zlib/inffast.h similarity index 100% rename from lib/zlib_inflate/inffast.h rename to lib/zlib/inffast.h diff --git a/lib/zlib_inflate/inffixed.h b/lib/zlib/inffixed.h similarity index 100% rename from lib/zlib_inflate/inffixed.h rename to lib/zlib/inffixed.h diff --git a/lib/zlib_inflate/inflate.c b/lib/zlib/inflate.c similarity index 100% rename from lib/zlib_inflate/inflate.c rename to lib/zlib/inflate.c index 7e1e311..ba58871 100644 --- a/lib/zlib_inflate/inflate.c +++ b/lib/zlib/inflate.c @@ -9,7 +9,7 @@ * */ -#include linux/zutil.h +#include zutil.h #include inftrees.h #include inflate.h #include inffast.h diff --git a/lib/zlib_inflate/inflate.h b/lib/zlib/inflate.h
[-mm] Move zlib compression library to common directory [TAKE TWO]
This patch moves the zlib compression and decompression code to a common directory. The zutil.h header, which is not meant to be public, is moved from include/linux/ to lib/zlib/. In addition, the PRESET_DICT definition from zutil.h, used by fs/jffs2/compr_zlib.c is moved to the 'true' 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/fs/jffs2/compr_zlib.c index 2b87fcc..e2cc6c7 100644 --- a/fs/jffs2/compr_zlib.c +++ b/fs/jffs2/compr_zlib.c @@ -16,7 +16,6 @@ #include linux/kernel.h #include linux/slab.h #include linux/zlib.h -#include linux/zutil.h #include nodelist.h #include compr.h diff --git a/include/linux/zlib.h b/include/linux/zlib.h index 9e3192a..e9d32c5 100644 --- a/include/linux/zlib.h +++ b/include/linux/zlib.h @@ -177,6 +177,9 @@ typedef z_stream *z_streamp; #define Z_DEFLATED 8 /* The deflate compression method (the only one supported in this version) */ +#define PRESET_DICT 0x20 /* preset dictionary flag in zlib header */ +/* Required by fs/jffs2/compr_zlib.c */ + /* basic functions */ extern int zlib_deflate_workspacesize (void); diff --git a/lib/Makefile b/lib/Makefile index c8c8e20..42c3903 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -46,8 +46,8 @@ obj-$(CONFIG_CRC32) += crc32.o obj-$(CONFIG_LIBCRC32C)+= libcrc32c.o obj-$(CONFIG_GENERIC_ALLOCATOR) += genalloc.o -obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate/ -obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate/ +obj-$(CONFIG_ZLIB_INFLATE) += zlib/ +obj-$(CONFIG_ZLIB_DEFLATE) += zlib/ obj-$(CONFIG_REED_SOLOMON) += reed_solomon/ obj-$(CONFIG_TEXTSEARCH) += textsearch.o diff --git a/lib/zlib_inflate/Makefile b/lib/zlib/Makefile similarity index 71% rename from lib/zlib_inflate/Makefile rename to lib/zlib/Makefile index bf06548..528d903 100644 --- a/lib/zlib_inflate/Makefile +++ b/lib/zlib/Makefile @@ -2,8 +2,8 @@ # This is a modified version of zlib, which does all memory # allocation ahead of time. # -# This is only the decompression, see zlib_deflate for the -# the compression +# The compression (deflate) and decompression (inflate) code +# is present in this folder. # # Decompression needs to be serialized for each memory # allocation. @@ -17,3 +17,7 @@ obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate.o zlib_inflate-objs := inffast.o inflate.o \ inftrees.o inflate_syms.o + +obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate.o + +zlib_deflate-objs := deflate.o deftree.o deflate_syms.o diff --git a/lib/zlib_deflate/deflate.c b/lib/zlib/deflate.c similarity index 100% rename from lib/zlib_deflate/deflate.c rename to lib/zlib/deflate.c index c3e4a2b..1137780 100644 --- a/lib/zlib_deflate/deflate.c +++ b/lib/zlib/deflate.c @@ -49,10 +49,9 @@ */ #include linux/module.h -#include linux/zutil.h +#include zutil.h #include defutil.h - /* === * Function prototypes. */ diff --git a/lib/zlib_deflate/deflate_syms.c b/lib/zlib/deflate_syms.c similarity index 100% rename from lib/zlib_deflate/deflate_syms.c rename to lib/zlib/deflate_syms.c diff --git a/lib/zlib_deflate/deftree.c b/lib/zlib/deftree.c similarity index 100% rename from lib/zlib_deflate/deftree.c rename to lib/zlib/deftree.c index ddf3482..d5ce87d 100644 --- a/lib/zlib_deflate/deftree.c +++ b/lib/zlib/deftree.c @@ -34,7 +34,7 @@ /* #include deflate.h */ -#include linux/zutil.h +#include zutil.h #include defutil.h #ifdef DEBUG_ZLIB diff --git a/lib/zlib_deflate/defutil.h b/lib/zlib/defutil.h similarity index 100% rename from lib/zlib_deflate/defutil.h rename to lib/zlib/defutil.h diff --git a/lib/zlib_inflate/inffast.c b/lib/zlib/inffast.c similarity index 100% rename from lib/zlib_inflate/inffast.c rename to lib/zlib/inffast.c index d84560c..50d3de1 100644 --- a/lib/zlib_inflate/inffast.c +++ b/lib/zlib/inffast.c @@ -3,7 +3,7 @@ * For conditions of distribution and use, see copyright notice in zlib.h */ -#include linux/zutil.h +#include zutil.h #include inftrees.h #include inflate.h #include inffast.h diff --git a/lib/zlib_inflate/inffast.h b/lib/zlib/inffast.h similarity index 100% rename from lib/zlib_inflate/inffast.h rename to lib/zlib/inffast.h diff --git a/lib/zlib_inflate/inffixed.h b/lib/zlib/inffixed.h similarity index 100% rename from lib/zlib_inflate/inffixed.h rename to lib/zlib/inffixed.h diff --git a/lib/zlib_inflate/inflate.c b/lib/zlib/inflate.c similarity index 100% rename from lib/zlib_inflate/inflate.c rename to lib/zlib/inflate.c index 7e1e311..ba58871 100644 --- a/lib/zlib_inflate/inflate.c +++ b/lib/zlib/inflate.c @@ -9,7 +9,7 @@ * */ -#include linux/zutil.h +#include zutil.h #include inftrees.h #include inflate.h #include inffast.h diff --git a/lib
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
On 28 May 2007, at 14:00, Pavel Machek wrote: I'm too lazy to figure out how it currently works, but I'll just state it is not my fault Figuring out how a userspace/kernelspace interface works should not rely on having to read kernelspace code. Unfortunately, in the case 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-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/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
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 the firmware is not needed in situations we try to work around here. I don't believe that it is impossible. What is needed is some thought, and maybe a loose spec. We need to think about safe ways of solving a simple problem: what to do when userspace is unable to respond to a kernel uevent request. We now have a timeout, whether it be handled synchronously or in the background. I don't think either solution is good enough. [RFC] Possible Plan: 1) request_firmware() should stick around unmodified but be marked __deprecated. 2) request_firmware_nowait() as it stands should probably be removed. After all, it only has 2 in-kernel users at the moment. 3) uevent interface should be notified when userspace handlers are / are not available so that events can be queued to be handled when userspace does turn up and re-register a hotplug event handler. 4) request_firmware_async() introduced: asynchronous firmware loading interface built on basis of 3, such that problems at early boot and suspend / resume are avoided. Also request_firmware_async() taught to retain firmware in memory by default such that subsequent calls do not require a call to userspace if userspace is unavailable. 6) Documentation on correct firmware loading behaviour for driver authors written, together with migration notes for existing users of request_firmware(). 7) Existing uses of request_firmware() converted. *Grumble ahead* Unfortunately, I don't properly understand the uevent interface, so some of the above may be inaccurate. This is *not* my fault as there is no decent documentation (and btw, telling me to write the documentation is not the answer to that problem). Michael-Luke - 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/
Re: [RFC] LZO de/compression support - take 5
On 28 May 2007, at 13:09, Nitin Gupta wrote: This means: 1) Options in lib/Kconfig hidden (selectable by drivers as required) LZO as hidden option has no practical sense. Although LZO should be auto-selected when some dependent project is selected (e.g. reieser4) - there should be separate patch for this. Mixing such changes with 'core' LZO patch will just add side noise. No, LZO as a visible option makes no practical sense. Why would anyone want to build LZO into a kernel when there are no in-kernel users of the code? In fact, all of the library code should probably go 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/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
On 28 May 2007, at 13:01, Kay Sievers wrote: In our development model, users of an interface are expected to improve it, because nobody else really knows what's needed. That unfortunately didn't happen so far. Thanks for responding :) The fact that no-one is told to use the new right way (tm) in any available documentation does not help matters improve. One issue is that the 'asynchronous' interface seems to rely on the same 'dodgy' timeout mechanism as the original request_firmware() call... Looks like the lack of a maintainer should be the opportunity 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/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
On 28 May 2007, at 12:24, Kay Sievers wrote: A driver for a bootup-critical device like this should just never release the firmware after the first load. There is absolutely no point in doing that. Bogus argument: is a USB-Ethernet device which needs firmware loading boot-up critical? 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 "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/
Re: [RFC] LZO de/compression support - take 5
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 Kconfig should be made orthogonal to the current zlib selection code. This means: 1) Options in lib/Kconfig hidden (selectable by drivers as required) 2) Decompression and Compression support separated, as read-only filesystems only need to build in decompression support. Thanks, Michael-Luke - 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/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
Now a technical rather than emotional response... On 28 May 2007, at 10:06, Kay Sievers wrote: At device driver load, firmware loading must be asynchronous. This is because device driver init can occur before userspace runs and registers a hotplug/uevent event handler. If device use is attempted before firmware loads, a -ENOFIRMWARE call would be great so that userspace and thus the user can be clearly informed what the problem is. Why would a driver create an interface before it has the needed firmware loaded? A valid point. But there should be some kind of error notification if firmware loading hasn't happened correctly rather than a permanent asynchronous wait in which the interface fails to turn up. Possibly a kernel information printk or something, which does not exist at the moment. However, at 'first use' firmware loading, the synchronous interface should remain. 'ifconfig up' either works or it doesn't, and as I see it, has to just hang around until firmware turns up. What kind of network driver does create an interface for a non-functioning device? That sounds like a bug on its own. Unclear. My point was that when ifconfig up exits, the interface should be up, not asynchronously waiting for firmware to be loaded, then taken up in the background. Thus, firmware loading in this case should be kept synchronous, in my opinion. If a driver binds to a device, it should just have the firmware already loaded, and not wait until its used. What's the reason for such a behavior, to let a driver pretend it can handle a device, but it doesn't even know if all the needed pieces are available on the system? Basically, you have a device which can carry out different functions depending on the firmware loaded into it. Driver A is specific to this device, and loads the firmware. Driver B uses functions exported by Driver A to carry out one particular function of the device. Driver C uses the same functions to carry out a totally different function on the same device, but with different firmware loaded. Add in multiple devices handled by Driver A, all with different functionality, and sometimes with combinations of functionality that can coexist, and you see that when Driver A loads it cannot possibly know which firmware to load, but must wait for other Drivers to turn up and be put into use. Thus it 'pretends' to handle all the devices until it's forced to make a choice. Yes, this is hellishly complicated. Blame Intel :) The underlying issue are the driver authors, that's not so easy to fix. :) Addressed in previous email. Well, 10 seconds are just to short for userspace to react on some setups, from tiny boxes which are busy, to 512 CPU boxes enumerating thousands of devices, all had problems here. Any timeout for a firmware-request is just a broken concept, the request should wait forever, to be fulfilled or canceled 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 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/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
On 28 May 2007, at 10:06, Kay Sievers wrote: The underlying issue are the driver authors, that's not so easy to fix. :) Sorry, I know this maybe be unintentional, but comments like this make me somewhat angry. If there is no decent documentation as to how to do it the right way (tm), how do you expect people to do it the right way (tm)? Any timeout for a firmware-request is just a broken concept, the request should wait forever, to be fulfilled or canceled from userspace when it's ready. What I wrote above is especially true when the in-kernel APIs themselves do things the wrong way (tm) themselves. Thus, even more thought is required to work around this imperfect behaviour in a sane manner. And without documentation, every single device driver author has to go through this thought process themselves. Unsurprisingly, they often get it wrong. But as there's no decent documentation to do it right, it's *not* their fault. I'd suggest it's more the fault of the core kernel devs who fail to fix up a questionable firmware loading interface, then fail to document how to work around its shortcomings. Again, apologies if this sounds angry, I don't want to start an argument. But as someone just starting out here, this kind of thing can be very frustrating, as even with the best will in the world, achieving the right way (tm) is basically impossible if those in the know about what the right way (tm) 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/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
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 kernel, it just causes all sorts of problems since it exists. Userspace should handle the async request just fine when it comes back running, regardless of the time it was submitted. Okay, so the solution is to convert the drivers to use request_firmware_nowait() instead of request_firmware() in their .resume() routines. [added Rob Landley to CC] I think asynchronous loading should be made the default behaviour. However, we need to think and document how to do firmware loading. Firmware loading can be done at two different times: Device Driver Load First use of Device Driver For a network device, this correlates to when the driver is first loaded into memory or at 'ifconfig up' respectively. At device driver load, firmware loading must be asynchronous. This is because device driver init can occur before userspace runs and registers a hotplug/uevent event handler. If device use is attempted before firmware loads, a -ENOFIRMWARE call would be great so that userspace and thus the user can be clearly informed what the problem is. However, at 'first use' firmware loading, the synchronous interface should remain. 'ifconfig up' either works or it doesn't, and as I see it, has to just hang around until firmware turns up. One more thing, it seems that the asynchronous firmware loading thread just spawns a _request_firmware() call which then times out at 60 seconds. I think, if the first request fails it spawns another. 60 seconds is *far* too long for this type of thing, and this was set at 10 seconds before the last two kernel releases (which is even a bit slow itself). Unfortunately, this appears to a case of quite senior kernel developers pushing a bodge upstream rather than fixing the underlying issue :( [1] [2] Documentation for how hotplug/uevent handlers should cope with these types of firmware loading is also *strongly* requested, in order for lightweight but fully functional implementations to be made. Documentation > Reference Implementation :) Michael-Luke [1] http://tinyurl.com/2colng (git.kernel.org) [2] http://tinyurl.com/224h54 (redhat bugzilla) - 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/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
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 kernel, it just causes all sorts of problems since it exists. Userspace should handle the async request just fine when it comes back running, regardless of the time it was submitted. Okay, so the solution is to convert the drivers to use request_firmware_nowait() instead of request_firmware() in their .resume() routines. [added Rob Landley to CC] I think asynchronous loading should be made the default behaviour. However, we need to think and document how to do firmware loading. Firmware loading can be done at two different times: Device Driver Load First use of Device Driver For a network device, this correlates to when the driver is first loaded into memory or at 'ifconfig up' respectively. At device driver load, firmware loading must be asynchronous. This is because device driver init can occur before userspace runs and registers a hotplug/uevent event handler. If device use is attempted before firmware loads, a -ENOFIRMWARE call would be great so that userspace and thus the user can be clearly informed what the problem is. However, at 'first use' firmware loading, the synchronous interface should remain. 'ifconfig up' either works or it doesn't, and as I see it, has to just hang around until firmware turns up. One more thing, it seems that the asynchronous firmware loading thread just spawns a _request_firmware() call which then times out at 60 seconds. I think, if the first request fails it spawns another. 60 seconds is *far* too long for this type of thing, and this was set at 10 seconds before the last two kernel releases (which is even a bit slow itself). Unfortunately, this appears to a case of quite senior kernel developers pushing a bodge upstream rather than fixing the underlying issue :( [1] [2] Documentation for how hotplug/uevent handlers should cope with these types of firmware loading is also *strongly* requested, in order for lightweight but fully functional implementations to be made. Documentation Reference Implementation :) Michael-Luke [1] http://tinyurl.com/2colng (git.kernel.org) [2] http://tinyurl.com/224h54 (redhat bugzilla) - 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/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
On 28 May 2007, at 10:06, Kay Sievers wrote: The underlying issue are the driver authors, that's not so easy to fix. :) Sorry, I know this maybe be unintentional, but comments like this make me somewhat angry. If there is no decent documentation as to how to do it the right way (tm), how do you expect people to do it the right way (tm)? Any timeout for a firmware-request is just a broken concept, the request should wait forever, to be fulfilled or canceled from userspace when it's ready. What I wrote above is especially true when the in-kernel APIs themselves do things the wrong way (tm) themselves. Thus, even more thought is required to work around this imperfect behaviour in a sane manner. And without documentation, every single device driver author has to go through this thought process themselves. Unsurprisingly, they often get it wrong. But as there's no decent documentation to do it right, it's *not* their fault. I'd suggest it's more the fault of the core kernel devs who fail to fix up a questionable firmware loading interface, then fail to document how to work around its shortcomings. Again, apologies if this sounds angry, I don't want to start an argument. But as someone just starting out here, this kind of thing can be very frustrating, as even with the best will in the world, achieving the right way (tm) is basically impossible if those in the know about what the right way (tm) 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/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
Now a technical rather than emotional response... On 28 May 2007, at 10:06, Kay Sievers wrote: At device driver load, firmware loading must be asynchronous. This is because device driver init can occur before userspace runs and registers a hotplug/uevent event handler. If device use is attempted before firmware loads, a -ENOFIRMWARE call would be great so that userspace and thus the user can be clearly informed what the problem is. Why would a driver create an interface before it has the needed firmware loaded? A valid point. But there should be some kind of error notification if firmware loading hasn't happened correctly rather than a permanent asynchronous wait in which the interface fails to turn up. Possibly a kernel information printk or something, which does not exist at the moment. However, at 'first use' firmware loading, the synchronous interface should remain. 'ifconfig up' either works or it doesn't, and as I see it, has to just hang around until firmware turns up. What kind of network driver does create an interface for a non-functioning device? That sounds like a bug on its own. Unclear. My point was that when ifconfig up exits, the interface should be up, not asynchronously waiting for firmware to be loaded, then taken up in the background. Thus, firmware loading in this case should be kept synchronous, in my opinion. If a driver binds to a device, it should just have the firmware already loaded, and not wait until its used. What's the reason for such a behavior, to let a driver pretend it can handle a device, but it doesn't even know if all the needed pieces are available on the system? Basically, you have a device which can carry out different functions depending on the firmware loaded into it. Driver A is specific to this device, and loads the firmware. Driver B uses functions exported by Driver A to carry out one particular function of the device. Driver C uses the same functions to carry out a totally different function on the same device, but with different firmware loaded. Add in multiple devices handled by Driver A, all with different functionality, and sometimes with combinations of functionality that can coexist, and you see that when Driver A loads it cannot possibly know which firmware to load, but must wait for other Drivers to turn up and be put into use. Thus it 'pretends' to handle all the devices until it's forced to make a choice. Yes, this is hellishly complicated. Blame Intel :) The underlying issue are the driver authors, that's not so easy to fix. :) Addressed in previous email. Well, 10 seconds are just to short for userspace to react on some setups, from tiny boxes which are busy, to 512 CPU boxes enumerating thousands of devices, all had problems here. Any timeout for a firmware-request is just a broken concept, the request should wait forever, to be fulfilled or canceled 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 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/
Re: [RFC] LZO de/compression support - take 5
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 Kconfig should be made orthogonal to the current zlib selection code. This means: 1) Options in lib/Kconfig hidden (selectable by drivers as required) 2) Decompression and Compression support separated, as read-only filesystems only need to build in decompression support. Thanks, Michael-Luke - 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/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
On 28 May 2007, at 12:24, Kay Sievers wrote: A driver for a bootup-critical device like this should just never release the firmware after the first load. There is absolutely no point in doing that. Bogus argument: is a USB-Ethernet device which needs firmware loading boot-up critical? 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 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/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
On 28 May 2007, at 13:01, Kay Sievers wrote: In our development model, users of an interface are expected to improve it, because nobody else really knows what's needed. That unfortunately didn't happen so far. Thanks for responding :) The fact that no-one is told to use the new right way (tm) in any available documentation does not help matters improve. One issue is that the 'asynchronous' interface seems to rely on the same 'dodgy' timeout mechanism as the original request_firmware() call... Looks like the lack of a maintainer should be the opportunity 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/
Re: [RFC] LZO de/compression support - take 5
On 28 May 2007, at 13:09, Nitin Gupta wrote: This means: 1) Options in lib/Kconfig hidden (selectable by drivers as required) LZO as hidden option has no practical sense. Although LZO should be auto-selected when some dependent project is selected (e.g. reieser4) - there should be separate patch for this. Mixing such changes with 'core' LZO patch will just add side noise. No, LZO as a visible option makes no practical sense. Why would anyone want to build LZO into a kernel when there are no in-kernel users of the code? In fact, all of the library code should probably go 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/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
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 the firmware is not needed in situations we try to work around here. I don't believe that it is impossible. What is needed is some thought, and maybe a loose spec. We need to think about safe ways of solving a simple problem: what to do when userspace is unable to respond to a kernel uevent request. We now have a timeout, whether it be handled synchronously or in the background. I don't think either solution is good enough. [RFC] Possible Plan: 1) request_firmware() should stick around unmodified but be marked __deprecated. 2) request_firmware_nowait() as it stands should probably be removed. After all, it only has 2 in-kernel users at the moment. 3) uevent interface should be notified when userspace handlers are / are not available so that events can be queued to be handled when userspace does turn up and re-register a hotplug event handler. 4) request_firmware_async() introduced: asynchronous firmware loading interface built on basis of 3, such that problems at early boot and suspend / resume are avoided. Also request_firmware_async() taught to retain firmware in memory by default such that subsequent calls do not require a call to userspace if userspace is unavailable. 6) Documentation on correct firmware loading behaviour for driver authors written, together with migration notes for existing users of request_firmware(). 7) Existing uses of request_firmware() converted. *Grumble ahead* Unfortunately, I don't properly understand the uevent interface, so some of the above may be inaccurate. This is *not* my fault as there is no decent documentation (and btw, telling me to write the documentation is not the answer to that problem). Michael-Luke - 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/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
On 28 May 2007, at 14:00, Pavel Machek wrote: I'm too lazy to figure out how it currently works, but I'll just state it is not my fault Figuring out how a userspace/kernelspace interface works should not rely on having to read kernelspace code. Unfortunately, in the case 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-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/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
On 27 May 2007, at 21:31, Rafael J. Wysocki wrote: From: Rafael J. Wysocki <[EMAIL PROTECTED]> Use a hibernation and suspend notifier to disable the firmware requesting mechanism before a hibernation/suspend and enable it after the operation. Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> drivers/base/firmware_class.c | 36 ++ ++ 1 file changed, 36 insertions(+) I don't like this approach, as I feel that the firmware loading interface should be able to detect if a firmware load request is not being handled, due to absence of userspace / hotplug handler presence. Other circumstances in which this can be a problem is during bootup when request_firmware() calls can be made before userspace is up and init has run (even in the presence of an initramfs). (Slightly OT: A particularly nasty race is when an initramfs userspace is present, but firmware loading cannot occur because init has not run, so proc hasn't been mounted, so a hotplug event handler cannot be registered, despite the fact that the firmware is sitting on the ramdisk mounted correctly...) In short, a more general solution would 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 PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
On 27 May 2007, at 21:31, Rafael J. Wysocki wrote: From: Rafael J. Wysocki [EMAIL PROTECTED] Use a hibernation and suspend notifier to disable the firmware requesting mechanism before a hibernation/suspend and enable it after the operation. Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] drivers/base/firmware_class.c | 36 ++ ++ 1 file changed, 36 insertions(+) I don't like this approach, as I feel that the firmware loading interface should be able to detect if a firmware load request is not being handled, due to absence of userspace / hotplug handler presence. Other circumstances in which this can be a problem is during bootup when request_firmware() calls can be made before userspace is up and init has run (even in the presence of an initramfs). (Slightly OT: A particularly nasty race is when an initramfs userspace is present, but firmware loading cannot occur because init has not run, so proc hasn't been mounted, so a hotplug event handler cannot be registered, despite the fact that the firmware is sitting on the ramdisk mounted correctly...) In short, a more general solution would 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 PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] LZO de/compression support - take 3
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 'unsafe' version on this basis. Michael-Luke - 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/
Re: [RFC] LZO de/compression support - take 3
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 'unsafe' version on this basis. Michael-Luke - 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/
Re: [RFC] LZO de/compression support - take 4
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 orthogonal with zlib's inflate and deflate support. Read only filesystems only have to decompress, for example. M-L - 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/
Re: [RFC] LZO de/compression support - take 4
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 orthogonal with zlib's inflate and deflate support. Read only filesystems only have to decompress, for example. M-L - 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/
Re: [RFC] [-mm] Remove 'unsafe' LZO decompressor
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 function, lowering the size of the minilzo.c file by nearly 500 out of an original 1727 lines. It also removes references to the 'unsafe' decompression function in the public LZO header and the EXPORT_SYMBOL_GPL declaration. This is intended to provoke some discussion over whether a decompression function able to scribble on arbitrary memory is desirable in the mainline kernel, whatever the performance increases. Over and above the security/stability implications of using this code, it can also be argued to represent an unnecessary duplication of the vast majority of LZO decompression code. This is due to the lack of likely in-kernel uses of the 'unsafe' function. Only a single user for this 'unsafe' code has been suggested, the 'Compressed Caching' project. This code is highly unlikely to move into mainline in the same timeframe as the LZO code. All of the other suggested uses require decompression of untrusted data, such that the 'safe' function should be used. Comments / disagreement all welcome :) This is obviously a highly desirable thing to do for a number of reasons. But have we quantified the performance difference? The author of LZO may be able to help us out here, so he's CCed as of this mail. Michael-Luke - 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/
[RFC] [-mm] Remove 'unsafe' LZO decompressor
Hi there, 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 function, lowering the size of the minilzo.c file by nearly 500 out of an original 1727 lines. It also removes references to the 'unsafe' decompression function in the public LZO header and the EXPORT_SYMBOL_GPL declaration. This is intended to provoke some discussion over whether a decompression function able to scribble on arbitrary memory is desirable in the mainline kernel, whatever the performance increases. Over and above the security/stability implications of using this code, it can also be argued to represent an unnecessary duplication of the vast majority of LZO decompression code. This is due to the lack of likely in-kernel uses of the 'unsafe' function. Only a single user for this 'unsafe' code has been suggested, the 'Compressed Caching' project. This code is highly unlikely to move into mainline in the same timeframe as the LZO code. All of the other suggested uses require decompression of untrusted data, such that the 'safe' function should be used. Comments / disagreement all welcome :) Michael-Luke Jones lzo-remove-unsafe-decompressor.patch Description: Binary data
[RFC] [-mm] Remove 'unsafe' LZO decompressor
Hi there, 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 function, lowering the size of the minilzo.c file by nearly 500 out of an original 1727 lines. It also removes references to the 'unsafe' decompression function in the public LZO header and the EXPORT_SYMBOL_GPL declaration. This is intended to provoke some discussion over whether a decompression function able to scribble on arbitrary memory is desirable in the mainline kernel, whatever the performance increases. Over and above the security/stability implications of using this code, it can also be argued to represent an unnecessary duplication of the vast majority of LZO decompression code. This is due to the lack of likely in-kernel uses of the 'unsafe' function. Only a single user for this 'unsafe' code has been suggested, the 'Compressed Caching' project. This code is highly unlikely to move into mainline in the same timeframe as the LZO code. All of the other suggested uses require decompression of untrusted data, such that the 'safe' function should be used. Comments / disagreement all welcome :) Michael-Luke Jones lzo-remove-unsafe-decompressor.patch Description: Binary data
Re: [RFC] [-mm] Remove 'unsafe' LZO decompressor
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 function, lowering the size of the minilzo.c file by nearly 500 out of an original 1727 lines. It also removes references to the 'unsafe' decompression function in the public LZO header and the EXPORT_SYMBOL_GPL declaration. This is intended to provoke some discussion over whether a decompression function able to scribble on arbitrary memory is desirable in the mainline kernel, whatever the performance increases. Over and above the security/stability implications of using this code, it can also be argued to represent an unnecessary duplication of the vast majority of LZO decompression code. This is due to the lack of likely in-kernel uses of the 'unsafe' function. Only a single user for this 'unsafe' code has been suggested, the 'Compressed Caching' project. This code is highly unlikely to move into mainline in the same timeframe as the LZO code. All of the other suggested uses require decompression of untrusted data, such that the 'safe' function should be used. Comments / disagreement all welcome :) This is obviously a highly desirable thing to do for a number of reasons. But have we quantified the performance difference? The author of LZO may be able to help us out here, so he's CCed as of this mail. Michael-Luke - 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/
Re: [RFC] LZO de/compression support - take 3
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 an easy trap to fall into. And one that an experienced dev *has* just fallen in to. M-L - 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/
Re: [RFC] LZO de/compression support - take 3
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 made this mistake once, then it'll happen again. In-kernel memory corruption is no fun. Safe/Secure == Default Michael-Luke - 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/
Re: [RFC] LZO de/compression support - take 3
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, I am concerned about the safety implications of including the 'unsafe' standard version in-kernel when likely uses include compression of network data, memory objects and so-on, all of which could in theory be maliciously modified. The 'unsafe' version is still included since in some scenarios we have guarantee that compressed data has not been modified (for e.g. where we keep compressed data in memory only). So, in those cases there is no need to go for slower 'safe' version. So, the version of decompressor selected should be left to the user (kernel dev) only - he should make sure that he is using the right version. Fair enough. However, this rather important issue is pretty much undocumented (source code comments don't count) and Reiser4 is already using the lzo1x_decompress() function rather than the seemingly more appropriate lzo1x_decompress_safe() function... http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22- rc2/2.6.22-rc2-mm1/broken-out/reiser4-use-lzo-library-functions.patch Perhaps a rename is in order: lzo1x_decompress() => lzo1x_decompress_unsafe() lzo1x_decompress_safe => lzo1x_decompress() M-L - 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/
Re: [RFC] LZO de/compression support - take 3
On 23 May 2007, at 09:27, Nitin Gupta wrote: This contains LZO1X-1 compressor and LZO1X decompressor (safe and standard version). I understand that the 'safe' decompression code is 'somewhat slower' and that decompressor performance is a key feature of this algorithm. However, I am concerned about the safety implications of including the 'unsafe' standard version in-kernel when likely uses include compression of network data, memory objects and so-on, all of which could in theory be maliciously modified. I'm no kernel or programming expert, 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: 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/
Re: [RFC] LZO de/compression support - take 3
On 23 May 2007, at 09:27, Nitin Gupta wrote: This contains LZO1X-1 compressor and LZO1X decompressor (safe and standard version). I understand that the 'safe' decompression code is 'somewhat slower' and that decompressor performance is a key feature of this algorithm. However, I am concerned about the safety implications of including the 'unsafe' standard version in-kernel when likely uses include compression of network data, memory objects and so-on, all of which could in theory be maliciously modified. I'm no kernel or programming expert, 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: 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/
Re: [RFC] LZO de/compression support - take 3
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, I am concerned about the safety implications of including the 'unsafe' standard version in-kernel when likely uses include compression of network data, memory objects and so-on, all of which could in theory be maliciously modified. The 'unsafe' version is still included since in some scenarios we have guarantee that compressed data has not been modified (for e.g. where we keep compressed data in memory only). So, in those cases there is no need to go for slower 'safe' version. So, the version of decompressor selected should be left to the user (kernel dev) only - he should make sure that he is using the right version. Fair enough. However, this rather important issue is pretty much undocumented (source code comments don't count) and Reiser4 is already using the lzo1x_decompress() function rather than the seemingly more appropriate lzo1x_decompress_safe() function... http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22- rc2/2.6.22-rc2-mm1/broken-out/reiser4-use-lzo-library-functions.patch Perhaps a rename is in order: lzo1x_decompress() = lzo1x_decompress_unsafe() lzo1x_decompress_safe = lzo1x_decompress() M-L - 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/
Re: [RFC] LZO de/compression support - take 3
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 made this mistake once, then it'll happen again. In-kernel memory corruption is no fun. Safe/Secure == Default Michael-Luke - 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/
Re: [RFC] LZO de/compression support - take 3
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 an easy trap to fall into. And one that an experienced dev *has* just fallen in to. M-L - 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/
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
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 only 10 additional lines of code [1]. Thus, there is no reason to assume that gaining LE support will be a major issue. Michael-Luke [1] 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) - 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/
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On 16 May 2007, at 08:13, Christoph Hellwig wrote: Not even trying to support LE is a clear merge blocker. Maybe Krzysztof can't actually test it himself, which is fine - but not even pretending to be endian clean is not what proper Linux drivers do. w.r.t this comment, a working 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 "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/
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On 16 May 2007, at 08:13, Christoph Hellwig wrote: Not even trying to support LE is a clear merge blocker. Maybe Krzysztof can't actually test it himself, which is fine - but not even pretending to be endian clean is not what proper Linux drivers do. w.r.t this comment, a working 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 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/
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
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 only 10 additional lines of code [1]. Thus, there is no reason to assume that gaining LE support will be a major issue. Michael-Luke [1] 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) - 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/
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
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 should not be mainlined before it has LE support. All that I said was: Personally I'd like LE ethernet tested and working before we push. The alternative would be to explicitly state in Kconfig that LE arm is broken with this driver, so that this could be fixed later. Please can we not blow this out of proportion, it really isn't that big a deal. The irony is that fixing Krzysztof's driver to work on LE will probably be quite easy, given that we already have a working LE driver from Christian. Michael-Luke PS: It really isn't just 'a few folks' - at NSLU2-Linux we have 5000 people who have downloaded Debian/LE for NSLU2 and are currently using Christian's driver with great success. We would just like to replicate that support with this new driver. - 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/
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
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 should not be mainlined before it has LE support. All that I said was: Personally I'd like LE ethernet tested and working before we push. The alternative would be to explicitly state in Kconfig that LE arm is broken with this driver, so that this could be fixed later. Please can we not blow this out of proportion, it really isn't that big a deal. The irony is that fixing Krzysztof's driver to work on LE will probably be quite easy, given that we already have a working LE driver from Christian. Michael-Luke PS: It really isn't just 'a few folks' - at NSLU2-Linux we have 5000 people who have downloaded Debian/LE for NSLU2 and are currently using Christian's driver with great success. We would just like to replicate that support with this new driver. - 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/
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
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 "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/
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
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 *cough* http://www.hohnstaedt.de/ixp_npe/0.2.0/0001-IXP4XX-Driver-for-NPE- QMGR-MAC-0.2.0.txt :p --- On 8 May 2007, at 09:29, Tomasz Chmielewski wrote: Christian Hohnstaedt's work did support LE though. Indeed. Krzysztof, why is LE not supported? Butting in here. It's not supported because LE mode has to work in a brain-damaged way. NPE DMAs the complete skb straight out of RAM. Unfortunately it expects the skb to already be written out in ram BE. Thus, in LE mode we have to byteswap the skb with CPU before the NPE can DMA it. This hasn't been implemented yet. 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/
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
0x4000
+
+/* Unassigned type: drive the data pins low (default), high, high
Z */
+#define PCR_TX_UNASS_HIGH 0x0800
+#define PCR_TX_UNASS_HIGH_IMP 0x1000
+
+/* T1 @ 1.544MHz only: Fbit dictated in FIFO (default) or high Z */
+#define PCR_TX_FB_HIGH_IMP 0x0400
+
+/* 56k data endiannes - which bit unused: high (default) or low */
+#define PCR_TX_56KE_BIT_0_UNUSED 0x0200
+
+/* 56k data transmission type: 32/8 bit data (default) or 56K data */
+#define PCR_TX_56KS_56K_DATA 0x0100
+
+/* hss_config, cCR */
+/* Number of packetized clients, default = 1 */
+#define CCR_NPE_HFIFO_2_HDLC 0x0400
+#define CCR_NPE_HFIFO_3_OR_4HDLC 0x0800
+
+/* default = no loopback */
+#define CCR_LOOPBACK 0x0200
+
+/* HSS number, default = 0 (first) */
+#define CCR_SECOND_HSS 0x0100
+
+
+/* hss_config, clkCR: main:10, num:10, denom:12 */
+#define CLK42X_SPEED_EXP ((0x3FF << 22) | ( 2 << 12) | 15) /*65
KHz*/
+
+#define CLK42X_SPEED_512KHZ(( 130 << 22) | ( 2 << 12) | 15)
+#define CLK42X_SPEED_1536KHZ (( 43 << 22) | ( 18 << 12) | 47)
+#define CLK42X_SPEED_1544KHZ (( 43 << 22) | ( 33 << 12) | 192)
+#define CLK42X_SPEED_2048KHZ (( 32 << 22) | ( 34 << 12) | 63)
+#define CLK42X_SPEED_4096KHZ (( 16 << 22) | ( 34 << 12) | 127)
+#define CLK42X_SPEED_8192KHZ ((8 << 22) | ( 34 << 12) | 255)
+
+#define CLK46X_SPEED_512KHZ(( 130 << 22) | ( 24 << 12) | 127)
+#define CLK46X_SPEED_1536KHZ (( 43 << 22) | (152 << 12) | 383)
+#define CLK46X_SPEED_1544KHZ (( 43 << 22) | ( 66 << 12) | 385)
+#define CLK46X_SPEED_2048KHZ (( 32 << 22) | (280 << 12) | 511)
+#define CLK46X_SPEED_4096KHZ (( 16 << 22) | (280 << 12) | 1023)
+#define CLK46X_SPEED_8192KHZ ((8 << 22) | (280 << 12) | 2047)
+
+
+/* hss_config, LUTs: default = unassigned */
+#define TDMMAP_HDLC1 /* HDLC - packetised */
+#define TDMMAP_VOICE56K2 /* Voice56K - channelised */
+#define TDMMAP_VOICE64K3 /* Voice64K - channelised */
+
+
+/* NPE command codes */
+/* writes the ConfigWord value to the location specified by offset */
+#define PORT_CONFIG_WRITE 0x40
+
+/* triggers the NPE to load the contents of the configuration
table */
+#define PORT_CONFIG_LOAD 0x41
+
+/* triggers the NPE to return an HssErrorReadResponse message */
+#define PORT_ERROR_READ0x42
+
+/* reset NPE internal status and enable the HssChannelized
operation */
+#define CHAN_FLOW_ENABLE 0x43
+#define CHAN_FLOW_DISABLE 0x44
+#define CHAN_IDLE_PATTERN_WRITE0x45
+#define CHAN_NUM_CHANS_WRITE 0x46
+#define CHAN_RX_BUF_ADDR_WRITE 0x47
+#define 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_ENABLE0x4C
+#define CHAN_TSLOTSWITCH_DISABLE 0x4D
+
+/* downloads the gainWord value for a timeslot switching channel
associated
+ with bypassNum */
+#define CHAN_TSLOTSWITCH_GCT_DOWNLOAD 0x4E
+
+/* triggers the NPE to reset internal status and enable the
HssPacketized
+ operation for the flow specified by pPipe */
Greater-than-one-line comments not conforming to Kernel coding style
- someone much more angry than me will jump on that.
+#define PKT_PIPE_FLOW_ENABLE 0x50
+#define PKT_PIPE_FLOW_DISABLE 0x51
+#define PKT_NUM_PIPES_WRITE0x52
+#define PKT_PIPE_FIFO_SIZEW_WRITE 0x53
+#define PKT_PIPE_HDLC_CFG_WRITE0x54
+#define PKT_PIPE_IDLE_PATTERN_WRITE0x55
+#define PKT_PIPE_RX_SIZE_WRITE 0x56
+#define PKT_PIPE_MODE_WRITE0x57
+
+
Lots of double returns.
+#define HSS_TIMESLOTS 128
+#define HSS_LUT_BITS 2
+
+/* HDLC packet status values - desc->status */
+#define ERR_SHUTDOWN 1 /* stop or shutdown occurrance */
+#define ERR_HDLC_ALIGN 2 /* HDLC alignment error */
+#define ERR_HDLC_FCS 3 /* HDLC Frame Check Sum error */
+#define ERR_RXFREE_Q_EMPTY 4 /* RX-free queue became empty while
receiving
+this packet (if buf_len < pkt_len) */
+#define ERR_HDLC_TOO_LONG 5 /* HDLC frame size too long */
+#define ERR_HDLC_ABORT 6 /* abort sequence received */
+#define ERR_DISCONNECTING 7 /* disconnect is in progress */
+
+
+struct port {
+ struct npe *npe;
+ struct net_device *netdev;
+ struct hss_plat_info *plat;
+ struct sk_buff *rx_skb_tab[RX_DESCS], *tx_skb_tab[TX_DESCS];
+ struct desc *desc_tab; /* coherent */
+ u32 desc_tab_phys;
+ sync_serial_settings settings;
+ int id;
+ u8 hdlc_cfg;
+};
+
[snip]
Again, looking good.
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/
Re: [PATCH] Intel IXP4xx network drivers v.3 - QMGR
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..b9e9bd6
--- /dev/null
+++ b/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c
Already in mach-ixp4xx, so can just be called qmgr.c
@@ -0,0 +1,273 @@
+/*
+ * Intel IXP4xx Queue Manager driver for Linux
+ *
+ * Copyright (C) 2007 Krzysztof Halasa <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of version 2 of the GNU General Public License
+ * as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+#define DEBUG 0
+
+struct qmgr_regs __iomem *qmgr_regs;
+static struct resource *mem_res;
+static spinlock_t qmgr_lock;
+static u32 used_sram_bitmap[4]; /* 128 16-dword pages */
+static void (*irq_handlers[HALF_QUEUES])(void *pdev);
+static void *irq_pdevs[HALF_QUEUES];
+
+void qmgr_set_irq(unsigned int queue, int src,
+ void (*handler)(void *pdev), void *pdev)
+{
+ u32 __iomem *reg = _regs->irqsrc[queue / 8]; /* 8 queues /
u32 */
+ int bit = (queue % 8) * 4; /* 3 bits + 1 reserved bit per queue */
+ unsigned long flags;
+
+ src &= 7;
+ spin_lock_irqsave(_lock, flags);
+ __raw_writel((__raw_readl(reg) & ~(7 << bit)) | (src << bit), reg);
+ irq_handlers[queue] = handler;
+ irq_pdevs[queue] = pdev;
+ spin_unlock_irqrestore(_lock, flags);
+}
+
+
+static irqreturn_t qmgr_irq1(int irq, void *pdev)
+{
+ int i;
+ u32 val = __raw_readl(_regs->irqstat[0]);
+ __raw_writel(val, _regs->irqstat[0]); /* ACK */
+
+ for (i = 0; i < HALF_QUEUES; i++)
+ if (val & (1 << i))
+ irq_handlers[i](irq_pdevs[i]);
+
+ return val ? IRQ_HANDLED : 0;
+}
+
+
+void qmgr_enable_irq(unsigned int queue)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(_lock, flags);
+ __raw_writel(__raw_readl(_regs->irqen[0]) | (1 << queue),
+_regs->irqen[0]);
+ spin_unlock_irqrestore(_lock, flags);
+}
+
+void qmgr_disable_irq(unsigned int queue)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(_lock, flags);
+ __raw_writel(__raw_readl(_regs->irqen[0]) & ~(1 << queue),
+_regs->irqen[0]);
+ spin_unlock_irqrestore(_lock, flags);
+}
+
+static inline void shift_mask(u32 *mask)
+{
+ mask[3] = mask[3] << 1 | mask[2] >> 31;
+ mask[2] = mask[2] << 1 | mask[1] >> 31;
+ mask[1] = mask[1] << 1 | mask[0] >> 31;
+ mask[0] <<= 1;
+}
+
+int qmgr_request_queue(unsigned int queue, unsigned int len /*
dwords */,
+ unsigned int nearly_empty_watermark,
+ unsigned int nearly_full_watermark)
+{
+ u32 cfg, addr = 0, mask[4]; /* in 16-dwords */
+ int err;
+
+ if (queue >= HALF_QUEUES)
+ return -ERANGE;
+
+ if ((nearly_empty_watermark | nearly_full_watermark) & ~7)
+ return -EINVAL;
+
+ switch (len) {
+ case 16:
+ cfg = 0 << 24;
+ mask[0] = 0x1;
+ break;
+ case 32:
+ cfg = 1 << 24;
+ mask[0] = 0x3;
+ break;
+ case 64:
+ cfg = 2 << 24;
+ mask[0] = 0xF;
+ break;
+ case 128:
+ cfg = 3 << 24;
+ mask[0] = 0xFF;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ cfg |= nearly_empty_watermark << 26;
+ cfg |= nearly_full_watermark << 29;
+ len /= 16; /* in 16-dwords: 1, 2, 4 or 8 */
+ mask[1] = mask[2] = mask[3] = 0;
+
+ if (!try_module_get(THIS_MODULE))
+ return -ENODEV;
+
+ spin_lock_irq(_lock);
+ if (__raw_readl(_regs->sram[queue])) {
+ err = -EBUSY;
+ goto err;
+ }
+
+ while (1) {
+ if (!(used_sram_bitmap[0] & mask[0]) &&
+ !(used_sram_bitmap[1] & mask[1]) &&
+ !(used_sram_bitmap[2] & mask[2]) &&
+ !(used_sram_bitmap[3] & mask[3]))
+ break; /* found free space */
+
+ addr++;
+ shift_mask(mask);
+ if (addr + len > ARRAY_SIZE(qmgr_regs->sram)) {
+ printk(KERN_ERR "qmgr: no free SRAM space for"
+ " queue %i\n", queue);
+ err = -ENOMEM;
+ goto err;
+ }
+ }
+
+ used_sram_bitmap[0] |= mask[0];
+ used_sram_bitmap[1] |= mask[1];
+ used_sram_bitmap[2] |= mask[2];
+ used_sram_bitmap[3] |= mask[3];
+ __raw_writel(cfg | (addr << 14), _regs->sram[queue]);
+
Re: [PATCH] Intel IXP4xx network drivers v.2 - NPE
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/arch/arm/mach-
ixp4xx/ixp4xx_npe.c
new file mode 100644
index 000..4c77d8a
--- /dev/null
+++ b/arch/arm/mach-ixp4xx/ixp4xx_npe.c
Already in mach-ixp4xx, so can just be called npe.c
@@ -0,0 +1,737 @@
+/*
+ * Intel IXP4xx Network Processor Engine driver for Linux
+ *
+ * Copyright (C) 2007 Krzysztof Halasa <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of version 2 of the GNU General Public License
+ * as published by the Free Software Foundation.
+ *
+ * The code is based on publicly available information:
+ * - Intel IXP4xx Developer's Manual and other e-papers
+ * - Intel IXP400 Access Library Software (BSD license)
+ * - previous works by Christian Hohnstaedt
<[EMAIL PROTECTED]>
+ * Thanks, Christian.
+ */
[snip]
+int npe_load_firmware(struct npe *npe, const char *name, struct
device *dev)
+{
+ const struct firmware *fw_entry;
+
+ struct dl_block {
+ u32 type;
+ u32 offset;
+ } *blk;
+
+ struct dl_image {
+ u32 magic;
+ u32 id;
+ u32 size;
+ union {
+ u32 data[0];
+ struct dl_block blocks[0];
+ };
+ } *image;
+
+ struct dl_codeblock {
+ u32 npe_addr;
+ u32 size;
+ u32 data[0];
+ } *cb;
+
+ int i, j, err, data_size, instr_size, blocks, table_end;
+ u32 cmd;
+
+ if ((err = request_firmware(_entry, name, dev)) != 0)
+ return err;
+
+ err = -EINVAL;
+ if (fw_entry->size < sizeof(struct dl_image)) {
+ print_npe(KERN_ERR, npe, "incomplete firmware file\n");
+ goto err;
+ }
+ image = (struct dl_image*)fw_entry->data;
+
+#if DEBUG_FW
+ print_npe(KERN_DEBUG, npe, "firmware: %08X %08X %08X (0x%X bytes)
\n",
+ image->magic, image->id, image->size, image->size * 4);
+#endif
+
+ if (image->magic == swab32(FW_MAGIC)) { /* swapped file */
+ image->id = swab32(image->id);
+ image->size = swab32(image->size);
+ } else if (image->magic != FW_MAGIC) {
+ print_npe(KERN_ERR, npe, "bad firmware file magic: 0x%X\n",
+ image->magic);
+ goto err;
+ }
+ if ((image->size * 4 + sizeof(struct dl_image)) != fw_entry->size) {
+ print_npe(KERN_ERR, npe,
+ "inconsistent size of firmware file\n");
+ goto err;
+ }
+ if (((image->id >> 24) & 0xF /* NPE ID */) != npe->id) {
+ print_npe(KERN_ERR, npe, "firmware file NPE ID mismatch\n");
+ goto err;
+ }
+ if (image->magic == swab32(FW_MAGIC))
+ for (i = 0; i < image->size; i++)
+ image->data[i] = swab32(image->data[i]);
+
+ if (!cpu_is_ixp46x() && ((image->id >> 28) & 0xF /* device ID */)) {
+ print_npe(KERN_INFO, npe, "IXP46x firmware ignored on "
+ "IXP42x\n");
+ goto err;
+ }
+
+ if (npe_running(npe)) {
+ print_npe(KERN_INFO, npe, "unable to load firmware, NPE is "
+ "already running\n");
+ err = -EBUSY;
+ goto err;
+ }
+#if 0
+ npe_stop(npe);
+ npe_reset(npe);
+#endif
Debugging code? Can this go?
+ print_npe(KERN_INFO, npe, "firmware functionality 0x%X, "
+ "revision 0x%X:%X\n", (image->id >> 16) & 0xFF,
+ (image->id >> 8) & 0xFF, image->id & 0xFF);
+
+ if (!cpu_is_ixp46x()) {
+ if (!npe->id)
+ instr_size = NPE_A_42X_INSTR_SIZE;
+ else
+ instr_size = NPE_B_AND_C_42X_INSTR_SIZE;
+ data_size = NPE_42X_DATA_SIZE;
+ } else {
+ instr_size = NPE_46X_INSTR_SIZE;
+ data_size = NPE_46X_DATA_SIZE;
+ }
+
+ for (blocks = 0; blocks * sizeof(struct dl_block) / 4 < image->size;
+blocks++)
+ if (image->blocks[blocks].type == FW_BLOCK_TYPE_EOF)
+ break;
+ if (blocks * sizeof(struct dl_block) / 4 >= image->size) {
+ print_npe(KERN_INFO, npe, "firmware EOF block marker not "
+ "found\n");
+ goto err;
+ }
+
+#if DEBUG_FW
+ print_npe(KERN_DEBUG, npe, "%i firmware blocks found\n", blocks);
+#endif
+
+ table_end = blocks * sizeof(struct dl_block) / 4 + 1 /* EOF
marker */;
+ for (i = 0, blk = image->blocks; i <
Re: [PATCH] Intel IXP4xx network drivers v.2 - NPE
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/arch/arm/mach-
ixp4xx/ixp4xx_npe.c
new file mode 100644
index 000..4c77d8a
--- /dev/null
+++ b/arch/arm/mach-ixp4xx/ixp4xx_npe.c
Already in mach-ixp4xx, so can just be called npe.c
@@ -0,0 +1,737 @@
+/*
+ * Intel IXP4xx Network Processor Engine driver for Linux
+ *
+ * Copyright (C) 2007 Krzysztof Halasa [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of version 2 of the GNU General Public License
+ * as published by the Free Software Foundation.
+ *
+ * The code is based on publicly available information:
+ * - Intel IXP4xx Developer's Manual and other e-papers
+ * - Intel IXP400 Access Library Software (BSD license)
+ * - previous works by Christian Hohnstaedt
[EMAIL PROTECTED]
+ * Thanks, Christian.
+ */
[snip]
+int npe_load_firmware(struct npe *npe, const char *name, struct
device *dev)
+{
+ const struct firmware *fw_entry;
+
+ struct dl_block {
+ u32 type;
+ u32 offset;
+ } *blk;
+
+ struct dl_image {
+ u32 magic;
+ u32 id;
+ u32 size;
+ union {
+ u32 data[0];
+ struct dl_block blocks[0];
+ };
+ } *image;
+
+ struct dl_codeblock {
+ u32 npe_addr;
+ u32 size;
+ u32 data[0];
+ } *cb;
+
+ int i, j, err, data_size, instr_size, blocks, table_end;
+ u32 cmd;
+
+ if ((err = request_firmware(fw_entry, name, dev)) != 0)
+ return err;
+
+ err = -EINVAL;
+ if (fw_entry-size sizeof(struct dl_image)) {
+ print_npe(KERN_ERR, npe, incomplete firmware file\n);
+ goto err;
+ }
+ image = (struct dl_image*)fw_entry-data;
+
+#if DEBUG_FW
+ print_npe(KERN_DEBUG, npe, firmware: %08X %08X %08X (0x%X bytes)
\n,
+ image-magic, image-id, image-size, image-size * 4);
+#endif
+
+ if (image-magic == swab32(FW_MAGIC)) { /* swapped file */
+ image-id = swab32(image-id);
+ image-size = swab32(image-size);
+ } else if (image-magic != FW_MAGIC) {
+ print_npe(KERN_ERR, npe, bad firmware file magic: 0x%X\n,
+ image-magic);
+ goto err;
+ }
+ if ((image-size * 4 + sizeof(struct dl_image)) != fw_entry-size) {
+ print_npe(KERN_ERR, npe,
+ inconsistent size of firmware file\n);
+ goto err;
+ }
+ if (((image-id 24) 0xF /* NPE ID */) != npe-id) {
+ print_npe(KERN_ERR, npe, firmware file NPE ID mismatch\n);
+ goto err;
+ }
+ if (image-magic == swab32(FW_MAGIC))
+ for (i = 0; i image-size; i++)
+ image-data[i] = swab32(image-data[i]);
+
+ if (!cpu_is_ixp46x() ((image-id 28) 0xF /* device ID */)) {
+ print_npe(KERN_INFO, npe, IXP46x firmware ignored on
+ IXP42x\n);
+ goto err;
+ }
+
+ if (npe_running(npe)) {
+ print_npe(KERN_INFO, npe, unable to load firmware, NPE is
+ already running\n);
+ err = -EBUSY;
+ goto err;
+ }
+#if 0
+ npe_stop(npe);
+ npe_reset(npe);
+#endif
Debugging code? Can this go?
+ print_npe(KERN_INFO, npe, firmware functionality 0x%X,
+ revision 0x%X:%X\n, (image-id 16) 0xFF,
+ (image-id 8) 0xFF, image-id 0xFF);
+
+ if (!cpu_is_ixp46x()) {
+ if (!npe-id)
+ instr_size = NPE_A_42X_INSTR_SIZE;
+ else
+ instr_size = NPE_B_AND_C_42X_INSTR_SIZE;
+ data_size = NPE_42X_DATA_SIZE;
+ } else {
+ instr_size = NPE_46X_INSTR_SIZE;
+ data_size = NPE_46X_DATA_SIZE;
+ }
+
+ for (blocks = 0; blocks * sizeof(struct dl_block) / 4 image-size;
+blocks++)
+ if (image-blocks[blocks].type == FW_BLOCK_TYPE_EOF)
+ break;
+ if (blocks * sizeof(struct dl_block) / 4 = image-size) {
+ print_npe(KERN_INFO, npe, firmware EOF block marker not
+ found\n);
+ goto err;
+ }
+
+#if DEBUG_FW
+ print_npe(KERN_DEBUG, npe, %i firmware blocks found\n, blocks);
+#endif
+
+ table_end = blocks * sizeof(struct dl_block) / 4 + 1 /* EOF
marker */;
+ for (i = 0, blk = image-blocks; i blocks; i++, blk++) {
+ if (blk-offset image-size - sizeof(struct
Re: [PATCH] Intel IXP4xx network drivers v.3 - QMGR
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..b9e9bd6
--- /dev/null
+++ b/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c
Already in mach-ixp4xx, so can just be called qmgr.c
@@ -0,0 +1,273 @@
+/*
+ * Intel IXP4xx Queue Manager driver for Linux
+ *
+ * Copyright (C) 2007 Krzysztof Halasa [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of version 2 of the GNU General Public License
+ * as published by the Free Software Foundation.
+ */
+
+#include linux/interrupt.h
+#include linux/kernel.h
+#include asm/io.h
+#include asm/arch/qmgr.h
+
+#define DEBUG 0
+
+struct qmgr_regs __iomem *qmgr_regs;
+static struct resource *mem_res;
+static spinlock_t qmgr_lock;
+static u32 used_sram_bitmap[4]; /* 128 16-dword pages */
+static void (*irq_handlers[HALF_QUEUES])(void *pdev);
+static void *irq_pdevs[HALF_QUEUES];
+
+void qmgr_set_irq(unsigned int queue, int src,
+ void (*handler)(void *pdev), void *pdev)
+{
+ u32 __iomem *reg = qmgr_regs-irqsrc[queue / 8]; /* 8 queues /
u32 */
+ int bit = (queue % 8) * 4; /* 3 bits + 1 reserved bit per queue */
+ unsigned long flags;
+
+ src = 7;
+ spin_lock_irqsave(qmgr_lock, flags);
+ __raw_writel((__raw_readl(reg) ~(7 bit)) | (src bit), reg);
+ irq_handlers[queue] = handler;
+ irq_pdevs[queue] = pdev;
+ spin_unlock_irqrestore(qmgr_lock, flags);
+}
+
+
+static irqreturn_t qmgr_irq1(int irq, void *pdev)
+{
+ int i;
+ u32 val = __raw_readl(qmgr_regs-irqstat[0]);
+ __raw_writel(val, qmgr_regs-irqstat[0]); /* ACK */
+
+ for (i = 0; i HALF_QUEUES; i++)
+ if (val (1 i))
+ irq_handlers[i](irq_pdevs[i]);
+
+ return val ? IRQ_HANDLED : 0;
+}
+
+
+void qmgr_enable_irq(unsigned int queue)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(qmgr_lock, flags);
+ __raw_writel(__raw_readl(qmgr_regs-irqen[0]) | (1 queue),
+qmgr_regs-irqen[0]);
+ spin_unlock_irqrestore(qmgr_lock, flags);
+}
+
+void qmgr_disable_irq(unsigned int queue)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(qmgr_lock, flags);
+ __raw_writel(__raw_readl(qmgr_regs-irqen[0]) ~(1 queue),
+qmgr_regs-irqen[0]);
+ spin_unlock_irqrestore(qmgr_lock, flags);
+}
+
+static inline void shift_mask(u32 *mask)
+{
+ mask[3] = mask[3] 1 | mask[2] 31;
+ mask[2] = mask[2] 1 | mask[1] 31;
+ mask[1] = mask[1] 1 | mask[0] 31;
+ mask[0] = 1;
+}
+
+int qmgr_request_queue(unsigned int queue, unsigned int len /*
dwords */,
+ unsigned int nearly_empty_watermark,
+ unsigned int nearly_full_watermark)
+{
+ u32 cfg, addr = 0, mask[4]; /* in 16-dwords */
+ int err;
+
+ if (queue = HALF_QUEUES)
+ return -ERANGE;
+
+ if ((nearly_empty_watermark | nearly_full_watermark) ~7)
+ return -EINVAL;
+
+ switch (len) {
+ case 16:
+ cfg = 0 24;
+ mask[0] = 0x1;
+ break;
+ case 32:
+ cfg = 1 24;
+ mask[0] = 0x3;
+ break;
+ case 64:
+ cfg = 2 24;
+ mask[0] = 0xF;
+ break;
+ case 128:
+ cfg = 3 24;
+ mask[0] = 0xFF;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ cfg |= nearly_empty_watermark 26;
+ cfg |= nearly_full_watermark 29;
+ len /= 16; /* in 16-dwords: 1, 2, 4 or 8 */
+ mask[1] = mask[2] = mask[3] = 0;
+
+ if (!try_module_get(THIS_MODULE))
+ return -ENODEV;
+
+ spin_lock_irq(qmgr_lock);
+ if (__raw_readl(qmgr_regs-sram[queue])) {
+ err = -EBUSY;
+ goto err;
+ }
+
+ while (1) {
+ if (!(used_sram_bitmap[0] mask[0])
+ !(used_sram_bitmap[1] mask[1])
+ !(used_sram_bitmap[2] mask[2])
+ !(used_sram_bitmap[3] mask[3]))
+ break; /* found free space */
+
+ addr++;
+ shift_mask(mask);
+ if (addr + len ARRAY_SIZE(qmgr_regs-sram)) {
+ printk(KERN_ERR qmgr: no free SRAM space for
+ queue %i\n, queue);
+ err = -ENOMEM;
+ goto err;
+ }
+ }
+
+ used_sram_bitmap[0] |= mask[0];
+ used_sram_bitmap[1] |= mask[1];
+ used_sram_bitmap[2] |= mask[2];
+ used_sram_bitmap[3] |= mask[3];
+ __raw_writel(cfg | (addr
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
) | ( 34 12) | 63)
+#define CLK42X_SPEED_4096KHZ (( 16 22) | ( 34 12) | 127)
+#define CLK42X_SPEED_8192KHZ ((8 22) | ( 34 12) | 255)
+
+#define CLK46X_SPEED_512KHZ(( 130 22) | ( 24 12) | 127)
+#define CLK46X_SPEED_1536KHZ (( 43 22) | (152 12) | 383)
+#define CLK46X_SPEED_1544KHZ (( 43 22) | ( 66 12) | 385)
+#define CLK46X_SPEED_2048KHZ (( 32 22) | (280 12) | 511)
+#define CLK46X_SPEED_4096KHZ (( 16 22) | (280 12) | 1023)
+#define CLK46X_SPEED_8192KHZ ((8 22) | (280 12) | 2047)
+
+
+/* hss_config, LUTs: default = unassigned */
+#define TDMMAP_HDLC1 /* HDLC - packetised */
+#define TDMMAP_VOICE56K2 /* Voice56K - channelised */
+#define TDMMAP_VOICE64K3 /* Voice64K - channelised */
+
+
+/* NPE command codes */
+/* writes the ConfigWord value to the location specified by offset */
+#define PORT_CONFIG_WRITE 0x40
+
+/* triggers the NPE to load the contents of the configuration
table */
+#define PORT_CONFIG_LOAD 0x41
+
+/* triggers the NPE to return an HssErrorReadResponse message */
+#define PORT_ERROR_READ0x42
+
+/* reset NPE internal status and enable the HssChannelized
operation */
+#define CHAN_FLOW_ENABLE 0x43
+#define CHAN_FLOW_DISABLE 0x44
+#define CHAN_IDLE_PATTERN_WRITE0x45
+#define CHAN_NUM_CHANS_WRITE 0x46
+#define CHAN_RX_BUF_ADDR_WRITE 0x47
+#define 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_ENABLE0x4C
+#define CHAN_TSLOTSWITCH_DISABLE 0x4D
+
+/* downloads the gainWord value for a timeslot switching channel
associated
+ with bypassNum */
+#define CHAN_TSLOTSWITCH_GCT_DOWNLOAD 0x4E
+
+/* triggers the NPE to reset internal status and enable the
HssPacketized
+ operation for the flow specified by pPipe */
Greater-than-one-line comments not conforming to Kernel coding style
- someone much more angry than me will jump on that.
+#define PKT_PIPE_FLOW_ENABLE 0x50
+#define PKT_PIPE_FLOW_DISABLE 0x51
+#define PKT_NUM_PIPES_WRITE0x52
+#define PKT_PIPE_FIFO_SIZEW_WRITE 0x53
+#define PKT_PIPE_HDLC_CFG_WRITE0x54
+#define PKT_PIPE_IDLE_PATTERN_WRITE0x55
+#define PKT_PIPE_RX_SIZE_WRITE 0x56
+#define PKT_PIPE_MODE_WRITE0x57
+
+
Lots of double returns.
+#define HSS_TIMESLOTS 128
+#define HSS_LUT_BITS 2
+
+/* HDLC packet status values - desc-status */
+#define ERR_SHUTDOWN 1 /* stop or shutdown occurrance */
+#define ERR_HDLC_ALIGN 2 /* HDLC alignment error */
+#define ERR_HDLC_FCS 3 /* HDLC Frame Check Sum error */
+#define ERR_RXFREE_Q_EMPTY 4 /* RX-free queue became empty while
receiving
+this packet (if buf_len pkt_len) */
+#define ERR_HDLC_TOO_LONG 5 /* HDLC frame size too long */
+#define ERR_HDLC_ABORT 6 /* abort sequence received */
+#define ERR_DISCONNECTING 7 /* disconnect is in progress */
+
+
+struct port {
+ struct npe *npe;
+ struct net_device *netdev;
+ struct hss_plat_info *plat;
+ struct sk_buff *rx_skb_tab[RX_DESCS], *tx_skb_tab[TX_DESCS];
+ struct desc *desc_tab; /* coherent */
+ u32 desc_tab_phys;
+ sync_serial_settings settings;
+ int id;
+ u8 hdlc_cfg;
+};
+
[snip]
Again, looking good.
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/
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
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 *cough* http://www.hohnstaedt.de/ixp_npe/0.2.0/0001-IXP4XX-Driver-for-NPE- QMGR-MAC-0.2.0.txt :p --- On 8 May 2007, at 09:29, Tomasz Chmielewski wrote: Christian Hohnstaedt's work did support LE though. Indeed. Krzysztof, why is LE not supported? Butting in here. It's not supported because LE mode has to work in a brain-damaged way. NPE DMAs the complete skb straight out of RAM. Unfortunately it expects the skb to already be written out in ram BE. Thus, in LE mode we have to byteswap the skb with CPU before the NPE can DMA it. This hasn't been implemented yet. 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/
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
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 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/
Re: [PATCH 3/3] Intel IXP4xx network drivers
[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 = headers pollution. Headers for ixp4xx-specific hardware can surely live in the include/ asm-arm/arch-ixp4xx/ quite happily. All 4 drivers are, in fact, network (related) drivers. Despite their name, Network Processing Engines are independent coprocessors which are only coincidentally attached to MACs for ethernet / WAN purposes. If Intel would allow us to compile code for these coprocessors, we could get them to do lots of things other than networking. In fact, we already kind of can. Crypto is not networking, and if the kernel gains ixp4xx crypto support, that should be possible to enable independently of networking. They can also function as DMA engines, which should also be independent of networking functionality. So, the NPE driver (which is basically ixp4xx specific) should be, for practical purposes, networking-code agnostic. As it is a lump of code talking to an architecture specific piece of hardware, it should live in arch/arm/ rather than arch-independent drivers/ (NB: the publically reviewed version of Christian's ixp4xx_net driver had exactly this file layout, see below) Ethernet & HSS code should probably select NPE and QMGR (rather than depend) Actually, that's exactly what this patch do. but these options should still be exposed in arch/arm/mach- ixp4xx/Kconfig Sorry, unclear. That sentence was meant as a coherent whole - agreeing with you that the NPE dependency should use select but then pointing out that you should still be able to turn NPE support on in arch/arm/mach/ixp4xx/Kconfig even without selecting any of the network drivers. Why exactly? They are network devices, who would expect them there? How about the dependency mess (NET_ETHERNET etc.) that would be created? For networking devices point, see above. I don't fully understand the specifics, but Christian appeared to avoid any dependency mess in the publically reviewed version of his driver (as below). As I understand it, functions to talk to the NPE should appear in the NPE driver. The NPE driver should then be called by ethernet/wan/ crypto/dma(?) drivers to carry out the specific firmware-dependent tasks. I haven't reviewed your code in detail, so I can't comment on whether this is what you actually do or not. ==Links to the review of Christian's driver== [1/7] Register & NPE definitions: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 038082.html [2/7] Platform devices (thought unnecessary by Lennert in his review): http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 038086.html [3/7] Stub for Data/Address-Coherent mode setup: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 038083.html [4/7] QMGR driver: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 038278.html [5/7] NPE driver: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 038085.html [6/7] Ethernet driver: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 038087.html [7/7] Documentation: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 038088.html Sorry if I'm stating the obvious, but this is a public discussion and I want to make sure everyone who reads this can see what I mean. If they disagree with me despite this, so be it :) Mike-Luke - 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/
Re: [PATCH 3/3] Intel IXP4xx network drivers
On 7 May 2007, at 01:07, Krzysztof Halasa wrote: Adds IXP4xx drivers for built-in CPU components: - hardware queue manager - NPE (network coprocessors), - Ethernet ports, - HSS (sync serial) ports (currently only non-channelized HDLC). Both Ethernet and HSS drivers use queue manager and NPE driver and require external firmware file(s) available from www.intel.com. "Platform device" definitions for Ethernet ports on IXDP425 development platform are provided (though it has been tested on not yet available IXP425-based hardware only) Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]> Immediate comments as follows: (Krzysztof has already seen them in a private email but I'm putting them out so people can publically disagree with me if I have got this wrong.) Code placement: Queue Manager & NPE code => arch/arm/mach-ixp4xx WAN driver code => drivers/net/wan Eth code => drivers/net/arm Kconfig: I'm not convinced about 'config IXP4XX_NETDEVICES'. I'd lose it together with the drivers/net/ixp4xx directory Ethernet & HSS code should probably select NPE and QMGR (rather than depend) but these options 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] Intel IXP4xx network drivers
[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 = headers pollution. Headers for ixp4xx-specific hardware can surely live in the include/ asm-arm/arch-ixp4xx/ quite happily. All 4 drivers are, in fact, network (related) drivers. Despite their name, Network Processing Engines are independent coprocessors which are only coincidentally attached to MACs for ethernet / WAN purposes. If Intel would allow us to compile code for these coprocessors, we could get them to do lots of things other than networking. In fact, we already kind of can. Crypto is not networking, and if the kernel gains ixp4xx crypto support, that should be possible to enable independently of networking. They can also function as DMA engines, which should also be independent of networking functionality. So, the NPE driver (which is basically ixp4xx specific) should be, for practical purposes, networking-code agnostic. As it is a lump of code talking to an architecture specific piece of hardware, it should live in arch/arm/ rather than arch-independent drivers/ (NB: the publically reviewed version of Christian's ixp4xx_net driver had exactly this file layout, see below) Ethernet HSS code should probably select NPE and QMGR (rather than depend) Actually, that's exactly what this patch do. but these options should still be exposed in arch/arm/mach- ixp4xx/Kconfig Sorry, unclear. That sentence was meant as a coherent whole - agreeing with you that the NPE dependency should use select but then pointing out that you should still be able to turn NPE support on in arch/arm/mach/ixp4xx/Kconfig even without selecting any of the network drivers. Why exactly? They are network devices, who would expect them there? How about the dependency mess (NET_ETHERNET etc.) that would be created? For networking devices point, see above. I don't fully understand the specifics, but Christian appeared to avoid any dependency mess in the publically reviewed version of his driver (as below). As I understand it, functions to talk to the NPE should appear in the NPE driver. The NPE driver should then be called by ethernet/wan/ crypto/dma(?) drivers to carry out the specific firmware-dependent tasks. I haven't reviewed your code in detail, so I can't comment on whether this is what you actually do or not. ==Links to the review of Christian's driver== [1/7] Register NPE definitions: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 038082.html [2/7] Platform devices (thought unnecessary by Lennert in his review): http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 038086.html [3/7] Stub for Data/Address-Coherent mode setup: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 038083.html [4/7] QMGR driver: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 038278.html [5/7] NPE driver: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 038085.html [6/7] Ethernet driver: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 038087.html [7/7] Documentation: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-January/ 038088.html Sorry if I'm stating the obvious, but this is a public discussion and I want to make sure everyone who reads this can see what I mean. If they disagree with me despite this, so be it :) Mike-Luke - 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/
Re: [PATCH 3/3] Intel IXP4xx network drivers
On 7 May 2007, at 01:07, Krzysztof Halasa wrote: Adds IXP4xx drivers for built-in CPU components: - hardware queue manager - NPE (network coprocessors), - Ethernet ports, - HSS (sync serial) ports (currently only non-channelized HDLC). Both Ethernet and HSS drivers use queue manager and NPE driver and require external firmware file(s) available from www.intel.com. Platform device definitions for Ethernet ports on IXDP425 development platform are provided (though it has been tested on not yet available IXP425-based hardware only) Signed-off-by: Krzysztof Halasa [EMAIL PROTECTED] Immediate comments as follows: (Krzysztof has already seen them in a private email but I'm putting them out so people can publically disagree with me if I have got this wrong.) Code placement: Queue Manager NPE code = arch/arm/mach-ixp4xx WAN driver code = drivers/net/wan Eth code = drivers/net/arm Kconfig: I'm not convinced about 'config IXP4XX_NETDEVICES'. I'd lose it together with the drivers/net/ixp4xx directory Ethernet HSS code should probably select NPE and QMGR (rather than depend) but these options 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [QUESTION] Sata RAID
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://people.redhat.com/~heinzm/sw/dmraid/ and please read http://linux-ata.org/faq-sata-raid.html On Saturday 24 February 2007, Patrick Ale wrote: Hi, Quick question, Since I am going to open my server today to do some pata tests (for the weird detection problems people are giving me fantastic help with, no sarcasm, I really mean it) I thought: why not add two 320GB SATA disks on the SATA controller that the mainboard has. I am wondering: should I use the onboard RAID function? Is this supported by Linux? I remember back in "the old days (TM)" there were seperate (spelling) drivers for ataraid, how does the current 2.6 branch cope with the RAID functions of modern motherboards? I am aware that it is NOT hardware raid, the raid is done in the driver, which is why you need this fancy boot disk before installing Windows on your RAID set. Or would you suggest me to stick with MD devices? Cheers, Patrick Ale [EMAIL PROTECTED] "kun kasvan isoksi, halun olla poro" - 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/ - 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/
Re: [QUESTION] Sata RAID
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://people.redhat.com/~heinzm/sw/dmraid/ and please read http://linux-ata.org/faq-sata-raid.html On Saturday 24 February 2007, Patrick Ale wrote: Hi, Quick question, Since I am going to open my server today to do some pata tests (for the weird detection problems people are giving me fantastic help with, no sarcasm, I really mean it) I thought: why not add two 320GB SATA disks on the SATA controller that the mainboard has. I am wondering: should I use the onboard RAID function? Is this supported by Linux? I remember back in the old days (TM) there were seperate (spelling) drivers for ataraid, how does the current 2.6 branch cope with the RAID functions of modern motherboards? I am aware that it is NOT hardware raid, the raid is done in the driver, which is why you need this fancy boot disk before installing Windows on your RAID set. Or would you suggest me to stick with MD devices? Cheers, Patrick Ale [EMAIL PROTECTED] kun kasvan isoksi, halun olla poro - 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/ - 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/
Re: 2.6.21-rc1 NFS build error on x86/ARM with modular IPV6
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 On 21 Feb 2007, at 10:50, M.L. Jones wrote: Hi there, Just attempted a build of vanilla 2.6.21-rc1 and got a failure with our usual defconfig. Notably, we build IPV6 support as modular - this seems to be the source of the problem. If any other info is required, please ask. Thanks for your help, Michael-Luke Jones NSLU2-Linux Core Team ==Error== GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 net/built-in.o: In function `svc_udp_recvfrom': sysctl_net.c:(.text+0x79fb4): undefined reference to `__ipv6_addr_type' make[1]: *** [.tmp_vmlinux1] Error 1 - 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/
Re: 2.6.21-rc1 NFS build error on x86/ARM with modular IPV6
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 On 21 Feb 2007, at 10:50, M.L. Jones wrote: Hi there, Just attempted a build of vanilla 2.6.21-rc1 and got a failure with our usual defconfig. Notably, we build IPV6 support as modular - this seems to be the source of the problem. If any other info is required, please ask. Thanks for your help, Michael-Luke Jones NSLU2-Linux Core Team ==Error== GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 net/built-in.o: In function `svc_udp_recvfrom': sysctl_net.c:(.text+0x79fb4): undefined reference to `__ipv6_addr_type' make[1]: *** [.tmp_vmlinux1] Error 1 - 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/
Re: 2.6.21-rc1 build error on ARM with modular IPV6
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. 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 got a failure with our usual defconfig. Notably, we build IPV6 support as modular - this seems to be the source of the problem. If any other info is required, please ask. Thanks for your help, Michael-Luke Jones NSLU2-Linux Core Team ==Error== GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 net/built-in.o: In function `svc_udp_recvfrom': sysctl_net.c:(.text+0x79fb4): undefined reference to `__ipv6_addr_type' make[1]: *** [.tmp_vmlinux1] Error 1 - 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/
Re: 2.6.21-rc1 build error on ARM with modular IPV6
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 got a failure with our usual defconfig. Notably, we build IPV6 support as modular - this seems to be the source of the problem. If any other info is required, please ask. Thanks for your help, Michael-Luke Jones NSLU2-Linux Core Team ==Error== GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 net/built-in.o: In function `svc_udp_recvfrom': sysctl_net.c:(.text+0x79fb4): undefined reference to `__ipv6_addr_type' make[1]: *** [.tmp_vmlinux1] Error 1 ==Config== # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc1 # Wed Feb 21 02:32:29 2007 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_TIME=y CONFIG_MMU=y # CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ZONE_DMA=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y # CONFIG_VM_EVENT_COUNTERS is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y # CONFIG_IOSCHED_CFQ is not set # CONFIG_DEFAULT_AS is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="deadline" # # System Type # # CONFIG_ARCH_AAEC2000 is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set # CONFIG_ARCH_CLPS7500 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_CO285 is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set # CONFIG_ARCH_IMX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set # CONFIG_ARCH_IOP13XX is not set CONFIG_ARCH_IXP4XX=y # CONFIG_ARCH_IXP2000 is not set # CONFIG_ARCH_IXP23XX is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_NS9XXX is not set # CONFIG_ARCH_PNX4008 is not set # CONFIG_ARCH_PXA is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set # CONFIG_ARCH_OMAP is not set CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y # # Intel IXP4xx Implementation Options # # # IXP4xx Platforms # CONFIG_MACH_NSLU2=y CONFIG_MACH_AVILA=y CONFIG_MACH_LOFT=y # CONFIG_ARCH_ADI_COYOTE is not set CONFIG_ARCH_IXDP425=y # CONFIG_MACH_IXDPG425 is not set # CONFIG_MACH_IXDP465 is not set CONFIG_ARCH_IXCDP1100=y # CONFIG_ARCH_PRPMC1100 is not set CONFIG_MACH_NAS100D=y CONFIG_ARCH_IXDP4XX=y # CONFIG_MACH_GTWX5715 is not set # # IXP4xx Options # CONFIG_DMABOUNCE=y # CONFIG_IXP4XX_INDIRECT_PCI is not set # # Processor Type # CONFIG_CPU_32=y CONFIG_CPU_XSCALE=y CONFIG_CPU_32v5=y CONFIG_CPU_ABRT_EV5T=y CONFIG_CPU_CACHE_VIVT=y CONFIG_CPU_TLB_V4WBI=y CONFIG_CPU_CP15=y CONFIG_CPU_CP15_MMU=y # # Processor Features # CONFIG_ARM_THUMB=y # CONFIG_CPU_BIG_ENDIAN is not set # CONFIG_CPU_DCACHE_DISABLE is not set # CONFIG_OUTER_CACHE is not set # CONFIG_IWMMXT is not set CONFIG_XSCALE_PMU=y # # Bus support # CONFIG_PCI=y # # P
Re: 2.6.21-rc1 build error on ARM with modular IPV6
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 got a failure with our usual defconfig. Notably, we build IPV6 support as modular - this seems to be the source of the problem. If any other info is required, please ask. Thanks for your help, Michael-Luke Jones NSLU2-Linux Core Team ==Error== GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 net/built-in.o: In function `svc_udp_recvfrom': sysctl_net.c:(.text+0x79fb4): undefined reference to `__ipv6_addr_type' make[1]: *** [.tmp_vmlinux1] Error 1 ==Config== # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc1 # Wed Feb 21 02:32:29 2007 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_TIME=y CONFIG_MMU=y # CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ZONE_DMA=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y # CONFIG_VM_EVENT_COUNTERS is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y # CONFIG_IOSCHED_CFQ is not set # CONFIG_DEFAULT_AS is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=deadline # # System Type # # CONFIG_ARCH_AAEC2000 is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set # CONFIG_ARCH_CLPS7500 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_CO285 is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set # CONFIG_ARCH_IMX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set # CONFIG_ARCH_IOP13XX is not set CONFIG_ARCH_IXP4XX=y # CONFIG_ARCH_IXP2000 is not set # CONFIG_ARCH_IXP23XX is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_NS9XXX is not set # CONFIG_ARCH_PNX4008 is not set # CONFIG_ARCH_PXA is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set # CONFIG_ARCH_OMAP is not set CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y # # Intel IXP4xx Implementation Options # # # IXP4xx Platforms # CONFIG_MACH_NSLU2=y CONFIG_MACH_AVILA=y CONFIG_MACH_LOFT=y # CONFIG_ARCH_ADI_COYOTE is not set CONFIG_ARCH_IXDP425=y # CONFIG_MACH_IXDPG425 is not set # CONFIG_MACH_IXDP465 is not set CONFIG_ARCH_IXCDP1100=y # CONFIG_ARCH_PRPMC1100 is not set CONFIG_MACH_NAS100D=y CONFIG_ARCH_IXDP4XX=y # CONFIG_MACH_GTWX5715 is not set # # IXP4xx Options # CONFIG_DMABOUNCE=y # CONFIG_IXP4XX_INDIRECT_PCI is not set # # Processor Type # CONFIG_CPU_32=y CONFIG_CPU_XSCALE=y CONFIG_CPU_32v5=y CONFIG_CPU_ABRT_EV5T=y CONFIG_CPU_CACHE_VIVT=y CONFIG_CPU_TLB_V4WBI=y CONFIG_CPU_CP15=y CONFIG_CPU_CP15_MMU=y # # Processor Features # CONFIG_ARM_THUMB=y # CONFIG_CPU_BIG_ENDIAN is not set # CONFIG_CPU_DCACHE_DISABLE is not set # CONFIG_OUTER_CACHE is not set # CONFIG_IWMMXT is not set CONFIG_XSCALE_PMU=y # # Bus support # CONFIG_PCI=y # # PCCARD (PCMCIA/CardBus) support
Re: 2.6.21-rc1 build error on ARM with modular IPV6
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. 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 got a failure with our usual defconfig. Notably, we build IPV6 support as modular - this seems to be the source of the problem. If any other info is required, please ask. Thanks for your help, Michael-Luke Jones NSLU2-Linux Core Team ==Error== GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 net/built-in.o: In function `svc_udp_recvfrom': sysctl_net.c:(.text+0x79fb4): undefined reference to `__ipv6_addr_type' make[1]: *** [.tmp_vmlinux1] Error 1 - 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/
