Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Fri, 21 Sep 2007 19:47:17 -0700 > On Fri, 2007-09-21 at 10:49 -0700, David Miller wrote: > > From: Denys Vlasenko <[EMAIL PROTECTED]> > > Date: Fri, 21 Sep 2007 18:03:55 +0100 > > > > > Do patches look ok to you? > > > > I'm travelling so I haven't looked closely yet :-) > > > > Michael can take a look and I'll try to do so as well > > tonight. > > > > I've already reviewed the earlier versions of the patch and have made > some suggestions. This latest one looks ok to me and tested ok. > > I'll follow up later with another patch to remove all the zeros in other > firmware sections, and to remove the gzip headers completely. > > Acked-by: Michael Chan <[EMAIL PROTECTED]> I've added these patches to net-2.6.24, thanks. - 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 1/2] bnx2: factor out gzip unpacker
From: Michael Chan [EMAIL PROTECTED] Date: Fri, 21 Sep 2007 19:47:17 -0700 On Fri, 2007-09-21 at 10:49 -0700, David Miller wrote: From: Denys Vlasenko [EMAIL PROTECTED] Date: Fri, 21 Sep 2007 18:03:55 +0100 Do patches look ok to you? I'm travelling so I haven't looked closely yet :-) Michael can take a look and I'll try to do so as well tonight. I've already reviewed the earlier versions of the patch and have made some suggestions. This latest one looks ok to me and tested ok. I'll follow up later with another patch to remove all the zeros in other firmware sections, and to remove the gzip headers completely. Acked-by: Michael Chan [EMAIL PROTECTED] I've added these patches to net-2.6.24, thanks. - 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 1/2] bnx2: factor out gzip unpacker
On Sep 24, 2007, at 13:32:23, Lennart Sorensen wrote: On Fri, Sep 21, 2007 at 11:37:52PM +0100, Denys Vlasenko wrote: But I compile net/* into bzImage. I like netbooting :) Isn't it possible to netboot with an initramfs image? I am pretty sure I have seen some systems do exactly that. Yeah, I've got Debian boxes that have never *not* netbooted (one Dell Op^?^?Craptiplex box whose BIOS and ACPI sucks so bad it can't even load GRUB/LILO, although Windows somehow works fine). So they boot PXELinux using the PXE boot ROM on the NICs and it loads both a kernel and an initramfs into memory. Kernel is stock Debian and hardly has enough built-in to spit at you, let alone find network/ disks, but it manages to load everything it needs off the automagically-generated initramfs. Cheers, Kyle Moffett - 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 1/2] bnx2: factor out gzip unpacker
On Fri, Sep 21, 2007 at 11:37:52PM +0100, Denys Vlasenko wrote: > But I compile net/* into bzImage. I like netbooting :) Isn't it possible to netboot with an initramfs image? I am pretty sure I have seen some systems do exactly that. -- Len Sorensen - 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 1/2] bnx2: factor out gzip unpacker
On Fri, Sep 21, 2007 at 11:37:52PM +0100, Denys Vlasenko wrote: But I compile net/* into bzImage. I like netbooting :) Isn't it possible to netboot with an initramfs image? I am pretty sure I have seen some systems do exactly that. -- Len Sorensen - 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 1/2] bnx2: factor out gzip unpacker
On Sep 24, 2007, at 13:32:23, Lennart Sorensen wrote: On Fri, Sep 21, 2007 at 11:37:52PM +0100, Denys Vlasenko wrote: But I compile net/* into bzImage. I like netbooting :) Isn't it possible to netboot with an initramfs image? I am pretty sure I have seen some systems do exactly that. Yeah, I've got Debian boxes that have never *not* netbooted (one Dell Op^?^?Craptiplex box whose BIOS and ACPI sucks so bad it can't even load GRUB/LILO, although Windows somehow works fine). So they boot PXELinux using the PXE boot ROM on the NICs and it loads both a kernel and an initramfs into memory. Kernel is stock Debian and hardly has enough built-in to spit at you, let alone find network/ disks, but it manages to load everything it needs off the automagically-generated initramfs. Cheers, Kyle Moffett - 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 1/2] bnx2: factor out gzip unpacker
On Fri, 2007-09-21 at 10:49 -0700, David Miller wrote: > From: Denys Vlasenko <[EMAIL PROTECTED]> > Date: Fri, 21 Sep 2007 18:03:55 +0100 > > > Do patches look ok to you? > > I'm travelling so I haven't looked closely yet :-) > > Michael can take a look and I'll try to do so as well > tonight. > I've already reviewed the earlier versions of the patch and have made some suggestions. This latest one looks ok to me and tested ok. I'll follow up later with another patch to remove all the zeros in other firmware sections, and to remove the gzip headers completely. Acked-by: Michael Chan <[EMAIL PROTECTED]> - 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 1/2] bnx2: factor out gzip unpacker
On Fri, Sep 21, 2007 at 11:48:05PM +0100, Alan Cox wrote: > > According to an earlier thread, dgrs was never really maintained, > > written for hardware that was never really distributed widely, and very > > likely hasn't had users in years... if ever. > > > > If that picture is accurate (it's a story I was told), then I am > > definitely queueing up a deletion patch. > > I think thats sensible. If someone whines it can be put back but I really > don't think anyone will nobody did yet, please yell if you need a rebased patch. -- maks - 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 1/2] bnx2: factor out gzip unpacker
Denys Vlasenko wrote: On Friday 21 September 2007 20:33, Krzysztof Oledzki wrote: On Fri, 21 Sep 2007, Denys Vlasenko wrote: On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote: On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said: I plan to use gzip compression on following drivers' firmware, if patches will be accepted: textdata bss dec hex filename 17653 109968 240 127861 1f375 drivers/net/acenic.o 6628 120448 4 127080 1f068 drivers/net/dgrs.o ^^ Should this be redone to use the existing firmware loading framework to load the firmware instead? Not in every case. For example, bnx2 maintainer says that driver and firmware are closely tied for his driver. IOW: you upgrade kernel and your NIC is not working anymore. Firmware may come with a kernel. We have a "install modules", we can also add "install firmware". Install where? I boot my machine over NFS, and it has no hard drive. Special cases already fail when using distro-linked targets like "make install." Jeff - 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 1/2] bnx2: factor out gzip unpacker
> According to an earlier thread, dgrs was never really maintained, > written for hardware that was never really distributed widely, and very > likely hasn't had users in years... if ever. > > If that picture is accurate (it's a story I was told), then I am > definitely queueing up a deletion patch. I think thats sensible. If someone whines it can be put back but I really don't think anyone will - 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 1/2] bnx2: factor out gzip unpacker
On Friday 21 September 2007 20:33, Krzysztof Oledzki wrote: > > On Fri, 21 Sep 2007, Denys Vlasenko wrote: > > > On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote: > >> On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said: > >> > >>> I plan to use gzip compression on following drivers' firmware, > >>> if patches will be accepted: > >>> > >>>textdata bss dec hex filename > >>> 17653 109968 240 127861 1f375 drivers/net/acenic.o > >>>6628 120448 4 127080 1f068 drivers/net/dgrs.o > >>> ^^ > >> > >> Should this be redone to use the existing firmware loading framework to > >> load the firmware instead? > > > > Not in every case. > > > > For example, bnx2 maintainer says that driver and > > firmware are closely tied for his driver. IOW: you upgrade kernel > > and your NIC is not working anymore. > > Firmware may come with a kernel. We have a "install modules", we can also > add "install firmware". Install where? I boot my machine over NFS, and it has no hard drive. > > Another argument is to make kernel be able to bring up NICs > > without needing firmware images in initramfs/initrd/hard drive. > > It is not possible to bring up things like FC or WiFi without firmware, > what special is in classic NICs? Nothing. It is just not (yet?) decreed from The Very Top that all and every firmware image should be loaded using request_firmware(). Also people may want to gzip something else than firmware. -- vda - 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 1/2] bnx2: factor out gzip unpacker
On Friday 21 September 2007 21:13, Andi Kleen wrote: > Denys Vlasenko <[EMAIL PROTECTED]> writes: > > > > I plan to use gzip compression on following drivers' firmware, > > if patches will be accepted: > > > >textdata bss dec hex filename > > 17653 109968 240 127861 1f375 drivers/net/acenic.o > >6628 120448 4 127080 1f068 drivers/net/dgrs.o > > ^^ > > Just change the makefiles to always install gzip'ed modules > modutils knows how to unzip them on the fly. But I compile net/* into bzImage. I like netbooting :) -- vda - 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 1/2] bnx2: factor out gzip unpacker
Alan Cox wrote: For example, bnx2 maintainer says that driver and firmware are closely tied for his driver. IOW: you upgrade kernel and your NIC is not working anymore. Another argument is to make kernel be able to bring up NICs without needing firmware images in initramfs/initrd/hard drive. dgrs should be using the request_firmware interface. Actually dgrs is probably a good candidate for /dev/null According to an earlier thread, dgrs was never really maintained, written for hardware that was never really distributed widely, and very likely hasn't had users in years... if ever. If that picture is accurate (it's a story I was told), then I am definitely queueing up a deletion patch. Jeff - 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 1/2] bnx2: factor out gzip unpacker
> For example, bnx2 maintainer says that driver and > firmware are closely tied for his driver. IOW: you upgrade kernel > and your NIC is not working anymore. > > Another argument is to make kernel be able to bring up NICs > without needing firmware images in initramfs/initrd/hard drive. dgrs should be using the request_firmware interface. Actually dgrs is probably a good candidate for /dev/null Alan - 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 1/2] bnx2: factor out gzip unpacker
> Just change the makefiles to always install gzip'ed modules > modutils knows how to unzip them on the fly. But that leaves the uncompressed firmware blobs in .data that ends up in unswappable kernel memory. - R. - 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 1/2] bnx2: factor out gzip unpacker
Denys Vlasenko <[EMAIL PROTECTED]> writes: > > I plan to use gzip compression on following drivers' firmware, > if patches will be accepted: > >textdata bss dec hex filename > 17653 109968 240 127861 1f375 drivers/net/acenic.o >6628 120448 4 127080 1f068 drivers/net/dgrs.o > ^^ Just change the makefiles to always install gzip'ed modules modutils knows how to unzip them on the fly. That will catch all the firmware and all the other code too. -Andi - 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 1/2] bnx2: factor out gzip unpacker
On Fri, 21 Sep 2007, Denys Vlasenko wrote: On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote: On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said: I plan to use gzip compression on following drivers' firmware, if patches will be accepted: textdata bss dec hex filename 17653 109968 240 127861 1f375 drivers/net/acenic.o 6628 120448 4 127080 1f068 drivers/net/dgrs.o ^^ Should this be redone to use the existing firmware loading framework to load the firmware instead? Not in every case. For example, bnx2 maintainer says that driver and firmware are closely tied for his driver. IOW: you upgrade kernel and your NIC is not working anymore. Firmware may come with a kernel. We have a "install modules", we can also add "install firmware". Another argument is to make kernel be able to bring up NICs without needing firmware images in initramfs/initrd/hard drive. It is not possible to bring up things like FC or WiFi without firmware, what special is in classic NICs? Best regards, Krzysztof Olędzki
Re: [PATCH 1/2] bnx2: factor out gzip unpacker
On Fri, 21 Sep 2007 20:18:06 BST, Denys Vlasenko said: > On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote: > > Should this be redone to use the existing firmware loading framework to > > load the firmware instead? > > Not in every case. > > For example, bnx2 maintainer says that driver and > firmware are closely tied for his driver. IOW: you upgrade kernel > and your NIC is not working anymore. > > Another argument is to make kernel be able to bring up NICs > without needing firmware images in initramfs/initrd/hard drive. OK, I can live with "considered and decided against". :) pgpQ8Dn8OWNLy.pgp Description: PGP signature
Re: [PATCH 1/2] bnx2: factor out gzip unpacker
On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote: > On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said: > > > I plan to use gzip compression on following drivers' firmware, > > if patches will be accepted: > > > >textdata bss dec hex filename > > 17653 109968 240 127861 1f375 drivers/net/acenic.o > >6628 120448 4 127080 1f068 drivers/net/dgrs.o > > ^^ > > Should this be redone to use the existing firmware loading framework to > load the firmware instead? Not in every case. For example, bnx2 maintainer says that driver and firmware are closely tied for his driver. IOW: you upgrade kernel and your NIC is not working anymore. Another argument is to make kernel be able to bring up NICs without needing firmware images in initramfs/initrd/hard drive. -- vda - 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 1/2] bnx2: factor out gzip unpacker
On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said: > I plan to use gzip compression on following drivers' firmware, > if patches will be accepted: > >textdata bss dec hex filename > 17653 109968 240 127861 1f375 drivers/net/acenic.o >6628 120448 4 127080 1f068 drivers/net/dgrs.o > ^^ Should this be redone to use the existing firmware loading framework to load the firmware instead? pgpxgDFRcCcpF.pgp Description: PGP signature
Re: [PATCH 1/2] bnx2: factor out gzip unpacker
On Friday 21 September 2007 18:49, David Miller wrote: > From: Denys Vlasenko <[EMAIL PROTECTED]> > Date: Fri, 21 Sep 2007 18:03:55 +0100 > > > Do patches look ok to you? > > I'm travelling so I haven't looked closely yet :-) > > Michael can take a look and I'll try to do so as well > tonight. Good. I plan to use gzip compression on following drivers' firmware, if patches will be accepted: textdata bss dec hex filename 17653 109968 240 127861 1f375 drivers/net/acenic.o 6628 120448 4 127080 1f068 drivers/net/dgrs.o ^^ -- vda - 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 1/2] bnx2: factor out gzip unpacker
From: Denys Vlasenko <[EMAIL PROTECTED]> Date: Fri, 21 Sep 2007 18:03:55 +0100 > Do patches look ok to you? I'm travelling so I haven't looked closely yet :-) Michael can take a look and I'll try to do so as well tonight. - 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 1/2] bnx2: factor out gzip unpacker
On Friday 21 September 2007 17:14, David Miller wrote: > From: Denys Vlasenko <[EMAIL PROTECTED]> > Date: Fri, 21 Sep 2007 12:01:24 +0100 > > > Hi Jeff, > > BNX2 and TG3 patches goes through Michael Chan and myself, > and I usually merge them in instead of Jeff. Didn't know that, sorry. Do patches look ok to you? -- vda - 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 1/2] bnx2: factor out gzip unpacker
From: Denys Vlasenko <[EMAIL PROTECTED]> Date: Fri, 21 Sep 2007 12:01:24 +0100 > Hi Jeff, BNX2 and TG3 patches goes through Michael Chan and myself, and I usually merge them in instead of Jeff. - 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/
[PATCH 1/2] bnx2: factor out gzip unpacker
Hi Jeff,
This patch modifies gzip unpacking code in bnx2 driver so that
it does not depend on bnx2 internals. I will move this code
out of the driver and into zlib in follow-on patch.
It can be useful in other drivers which need to store firmwares
or any other relatively big binary blobs - fonts, cursor bitmaps,
whatever.
Patch is run tested by Michael Chan (driver author).
Michael, can you add your ACK?
Signed-off-by: Denys Vlasenko <[EMAIL PROTECTED]>
--
vda
diff -urpN linux-2.6.23-rc6/drivers/net/bnx2.c linux-2.6.23-rc6.bnx2/drivers/net/bnx2.c
--- linux-2.6.23-rc6/drivers/net/bnx2.c 2007-09-14 00:08:11.0 +0100
+++ linux-2.6.23-rc6.bnx2/drivers/net/bnx2.c 2007-09-21 11:44:03.0 +0100
@@ -52,6 +52,8 @@
#include "bnx2_fw.h"
#include "bnx2_fw2.h"
+#define FW_BUF_SIZE 0x8000
+
#define DRV_MODULE_NAME "bnx2"
#define PFX DRV_MODULE_NAME ": "
#define DRV_MODULE_VERSION "1.6.4"
@@ -2767,89 +2769,45 @@ bnx2_set_rx_mode(struct net_device *dev)
spin_unlock_bh(>phy_lock);
}
-#define FW_BUF_SIZE 0x8000
-
+/* To be moved to generic lib/ */
static int
-bnx2_gunzip_init(struct bnx2 *bp)
+bnx2_gunzip(void *gunzip_buf, unsigned sz, u8 *zbuf, int len)
{
- if ((bp->gunzip_buf = vmalloc(FW_BUF_SIZE)) == NULL)
- goto gunzip_nomem1;
+ struct z_stream_s *strm;
+ int rc;
- if ((bp->strm = kmalloc(sizeof(*bp->strm), GFP_KERNEL)) == NULL)
- goto gunzip_nomem2;
+ /* gzip header (1f,8b,08... 10 bytes total + possible asciz filename)
+ * is stripped */
- bp->strm->workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
- if (bp->strm->workspace == NULL)
+ rc = -ENOMEM;
+ strm = kmalloc(sizeof(*strm), GFP_KERNEL);
+ if (strm == NULL)
+ goto gunzip_nomem2;
+ strm->workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
+ if (strm->workspace == NULL)
goto gunzip_nomem3;
- return 0;
+ strm->next_in = zbuf;
+ strm->avail_in = len;
+ strm->next_out = gunzip_buf;
+ strm->avail_out = sz;
+
+ rc = zlib_inflateInit2(strm, -MAX_WBITS);
+ if (rc == Z_OK) {
+ rc = zlib_inflate(strm, Z_FINISH);
+ /* after Z_FINISH, only Z_STREAM_END is "we unpacked it all" */
+ if (rc == Z_STREAM_END)
+ rc = sz - strm->avail_out;
+ else
+ rc = -EINVAL;
+ zlib_inflateEnd(strm);
+ } else
+ rc = -EINVAL;
+ kfree(strm->workspace);
gunzip_nomem3:
- kfree(bp->strm);
- bp->strm = NULL;
-
+ kfree(strm);
gunzip_nomem2:
- vfree(bp->gunzip_buf);
- bp->gunzip_buf = NULL;
-
-gunzip_nomem1:
- printk(KERN_ERR PFX "%s: Cannot allocate firmware buffer for "
- "uncompression.\n", bp->dev->name);
- return -ENOMEM;
-}
-
-static void
-bnx2_gunzip_end(struct bnx2 *bp)
-{
- kfree(bp->strm->workspace);
-
- kfree(bp->strm);
- bp->strm = NULL;
-
- if (bp->gunzip_buf) {
- vfree(bp->gunzip_buf);
- bp->gunzip_buf = NULL;
- }
-}
-
-static int
-bnx2_gunzip(struct bnx2 *bp, u8 *zbuf, int len, void **outbuf, int *outlen)
-{
- int n, rc;
-
- /* check gzip header */
- if ((zbuf[0] != 0x1f) || (zbuf[1] != 0x8b) || (zbuf[2] != Z_DEFLATED))
- return -EINVAL;
-
- n = 10;
-
-#define FNAME 0x8
- if (zbuf[3] & FNAME)
- while ((zbuf[n++] != 0) && (n < len));
-
- bp->strm->next_in = zbuf + n;
- bp->strm->avail_in = len - n;
- bp->strm->next_out = bp->gunzip_buf;
- bp->strm->avail_out = FW_BUF_SIZE;
-
- rc = zlib_inflateInit2(bp->strm, -MAX_WBITS);
- if (rc != Z_OK)
- return rc;
-
- rc = zlib_inflate(bp->strm, Z_FINISH);
-
- *outlen = FW_BUF_SIZE - bp->strm->avail_out;
- *outbuf = bp->gunzip_buf;
-
- if ((rc != Z_OK) && (rc != Z_STREAM_END))
- printk(KERN_ERR PFX "%s: Firmware decompression error: %s\n",
- bp->dev->name, bp->strm->msg);
-
- zlib_inflateEnd(bp->strm);
-
- if (rc == Z_STREAM_END)
- return 0;
-
return rc;
}
@@ -2902,22 +2860,21 @@ load_cpu_fw(struct bnx2 *bp, struct cpu_
/* Load the Text area. */
offset = cpu_reg->spad_base + (fw->text_addr - cpu_reg->mips_view_base);
if (fw->gz_text) {
- u32 text_len;
- void *text;
-
- rc = bnx2_gunzip(bp, fw->gz_text, fw->gz_text_len, ,
- _len);
- if (rc)
- return rc;
-
- fw->text = text;
- }
- if (fw->gz_text) {
+ u32 *text;
int j;
+ text = vmalloc(FW_BUF_SIZE);
+ if (!text)
+ return -ENOMEM;
+ rc = bnx2_gunzip(text, FW_BUF_SIZE, fw->gz_text, fw->gz_text_len);
+ if (rc < 0) {
+ vfree(text);
+ return rc;
+ }
for (j = 0; j < (fw->text_len / 4); j++, offset += 4) {
- REG_WR_IND(bp, offset, cpu_to_le32(fw->text[j]));
+ REG_WR_IND(bp, offset, cpu_to_le32(text[j]));
}
+ vfree(text);
}
/* Load the Data area. */
@@ -2979,27 +2936,27 @@ bnx2_init_cpus(struct bnx2 *bp)
{
struct cpu_reg cpu_reg;
struct fw_info *fw;
- int rc = 0;
+ int rc;
void *text;
- u32 text_len;
-
- if ((rc = bnx2_gunzip_init(bp)) != 0)
- return rc;
/* Initialize the RV2P processor. */
- rc = bnx2_gunzip(bp, bnx2_rv2p_proc1, sizeof(bnx2_rv2p_proc1), ,
- _len);
- if (rc)
+ text = vmalloc(FW_BUF_SIZE);
+ if (!text)
+ return -ENOMEM;
+ rc = bnx2_gunzip(text, FW_BUF_SIZE, bnx2_rv2p_proc1, sizeof(bnx2_rv2p_proc1));
+ if (rc < 0)
[PATCH 1/2] bnx2: factor out gzip unpacker
Hi Jeff,
This patch modifies gzip unpacking code in bnx2 driver so that
it does not depend on bnx2 internals. I will move this code
out of the driver and into zlib in follow-on patch.
It can be useful in other drivers which need to store firmwares
or any other relatively big binary blobs - fonts, cursor bitmaps,
whatever.
Patch is run tested by Michael Chan (driver author).
Michael, can you add your ACK?
Signed-off-by: Denys Vlasenko [EMAIL PROTECTED]
--
vda
diff -urpN linux-2.6.23-rc6/drivers/net/bnx2.c linux-2.6.23-rc6.bnx2/drivers/net/bnx2.c
--- linux-2.6.23-rc6/drivers/net/bnx2.c 2007-09-14 00:08:11.0 +0100
+++ linux-2.6.23-rc6.bnx2/drivers/net/bnx2.c 2007-09-21 11:44:03.0 +0100
@@ -52,6 +52,8 @@
#include bnx2_fw.h
#include bnx2_fw2.h
+#define FW_BUF_SIZE 0x8000
+
#define DRV_MODULE_NAME bnx2
#define PFX DRV_MODULE_NAME :
#define DRV_MODULE_VERSION 1.6.4
@@ -2767,89 +2769,45 @@ bnx2_set_rx_mode(struct net_device *dev)
spin_unlock_bh(bp-phy_lock);
}
-#define FW_BUF_SIZE 0x8000
-
+/* To be moved to generic lib/ */
static int
-bnx2_gunzip_init(struct bnx2 *bp)
+bnx2_gunzip(void *gunzip_buf, unsigned sz, u8 *zbuf, int len)
{
- if ((bp-gunzip_buf = vmalloc(FW_BUF_SIZE)) == NULL)
- goto gunzip_nomem1;
+ struct z_stream_s *strm;
+ int rc;
- if ((bp-strm = kmalloc(sizeof(*bp-strm), GFP_KERNEL)) == NULL)
- goto gunzip_nomem2;
+ /* gzip header (1f,8b,08... 10 bytes total + possible asciz filename)
+ * is stripped */
- bp-strm-workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
- if (bp-strm-workspace == NULL)
+ rc = -ENOMEM;
+ strm = kmalloc(sizeof(*strm), GFP_KERNEL);
+ if (strm == NULL)
+ goto gunzip_nomem2;
+ strm-workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
+ if (strm-workspace == NULL)
goto gunzip_nomem3;
- return 0;
+ strm-next_in = zbuf;
+ strm-avail_in = len;
+ strm-next_out = gunzip_buf;
+ strm-avail_out = sz;
+
+ rc = zlib_inflateInit2(strm, -MAX_WBITS);
+ if (rc == Z_OK) {
+ rc = zlib_inflate(strm, Z_FINISH);
+ /* after Z_FINISH, only Z_STREAM_END is we unpacked it all */
+ if (rc == Z_STREAM_END)
+ rc = sz - strm-avail_out;
+ else
+ rc = -EINVAL;
+ zlib_inflateEnd(strm);
+ } else
+ rc = -EINVAL;
+ kfree(strm-workspace);
gunzip_nomem3:
- kfree(bp-strm);
- bp-strm = NULL;
-
+ kfree(strm);
gunzip_nomem2:
- vfree(bp-gunzip_buf);
- bp-gunzip_buf = NULL;
-
-gunzip_nomem1:
- printk(KERN_ERR PFX %s: Cannot allocate firmware buffer for
- uncompression.\n, bp-dev-name);
- return -ENOMEM;
-}
-
-static void
-bnx2_gunzip_end(struct bnx2 *bp)
-{
- kfree(bp-strm-workspace);
-
- kfree(bp-strm);
- bp-strm = NULL;
-
- if (bp-gunzip_buf) {
- vfree(bp-gunzip_buf);
- bp-gunzip_buf = NULL;
- }
-}
-
-static int
-bnx2_gunzip(struct bnx2 *bp, u8 *zbuf, int len, void **outbuf, int *outlen)
-{
- int n, rc;
-
- /* check gzip header */
- if ((zbuf[0] != 0x1f) || (zbuf[1] != 0x8b) || (zbuf[2] != Z_DEFLATED))
- return -EINVAL;
-
- n = 10;
-
-#define FNAME 0x8
- if (zbuf[3] FNAME)
- while ((zbuf[n++] != 0) (n len));
-
- bp-strm-next_in = zbuf + n;
- bp-strm-avail_in = len - n;
- bp-strm-next_out = bp-gunzip_buf;
- bp-strm-avail_out = FW_BUF_SIZE;
-
- rc = zlib_inflateInit2(bp-strm, -MAX_WBITS);
- if (rc != Z_OK)
- return rc;
-
- rc = zlib_inflate(bp-strm, Z_FINISH);
-
- *outlen = FW_BUF_SIZE - bp-strm-avail_out;
- *outbuf = bp-gunzip_buf;
-
- if ((rc != Z_OK) (rc != Z_STREAM_END))
- printk(KERN_ERR PFX %s: Firmware decompression error: %s\n,
- bp-dev-name, bp-strm-msg);
-
- zlib_inflateEnd(bp-strm);
-
- if (rc == Z_STREAM_END)
- return 0;
-
return rc;
}
@@ -2902,22 +2860,21 @@ load_cpu_fw(struct bnx2 *bp, struct cpu_
/* Load the Text area. */
offset = cpu_reg-spad_base + (fw-text_addr - cpu_reg-mips_view_base);
if (fw-gz_text) {
- u32 text_len;
- void *text;
-
- rc = bnx2_gunzip(bp, fw-gz_text, fw-gz_text_len, text,
- text_len);
- if (rc)
- return rc;
-
- fw-text = text;
- }
- if (fw-gz_text) {
+ u32 *text;
int j;
+ text = vmalloc(FW_BUF_SIZE);
+ if (!text)
+ return -ENOMEM;
+ rc = bnx2_gunzip(text, FW_BUF_SIZE, fw-gz_text, fw-gz_text_len);
+ if (rc 0) {
+ vfree(text);
+ return rc;
+ }
for (j = 0; j (fw-text_len / 4); j++, offset += 4) {
- REG_WR_IND(bp, offset, cpu_to_le32(fw-text[j]));
+ REG_WR_IND(bp, offset, cpu_to_le32(text[j]));
}
+ vfree(text);
}
/* Load the Data area. */
@@ -2979,27 +2936,27 @@ bnx2_init_cpus(struct bnx2 *bp)
{
struct cpu_reg cpu_reg;
struct fw_info *fw;
- int rc = 0;
+ int rc;
void *text;
- u32 text_len;
-
- if ((rc = bnx2_gunzip_init(bp)) != 0)
- return rc;
/* Initialize the RV2P processor. */
- rc = bnx2_gunzip(bp, bnx2_rv2p_proc1, sizeof(bnx2_rv2p_proc1), text,
- text_len);
- if (rc)
+ text = vmalloc(FW_BUF_SIZE);
+ if (!text)
+ return -ENOMEM;
+ rc = bnx2_gunzip(text, FW_BUF_SIZE, bnx2_rv2p_proc1, sizeof(bnx2_rv2p_proc1));
+ if (rc 0) {
+ vfree(text);
goto init_cpu_err;
+ }
+ load_rv2p_fw(bp, text,
Re: [PATCH 1/2] bnx2: factor out gzip unpacker
From: Denys Vlasenko [EMAIL PROTECTED] Date: Fri, 21 Sep 2007 12:01:24 +0100 Hi Jeff, BNX2 and TG3 patches goes through Michael Chan and myself, and I usually merge them in instead of Jeff. - 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 1/2] bnx2: factor out gzip unpacker
On Friday 21 September 2007 17:14, David Miller wrote: From: Denys Vlasenko [EMAIL PROTECTED] Date: Fri, 21 Sep 2007 12:01:24 +0100 Hi Jeff, BNX2 and TG3 patches goes through Michael Chan and myself, and I usually merge them in instead of Jeff. Didn't know that, sorry. Do patches look ok to you? -- vda - 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 1/2] bnx2: factor out gzip unpacker
From: Denys Vlasenko [EMAIL PROTECTED] Date: Fri, 21 Sep 2007 18:03:55 +0100 Do patches look ok to you? I'm travelling so I haven't looked closely yet :-) Michael can take a look and I'll try to do so as well tonight. - 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 1/2] bnx2: factor out gzip unpacker
On Friday 21 September 2007 18:49, David Miller wrote: From: Denys Vlasenko [EMAIL PROTECTED] Date: Fri, 21 Sep 2007 18:03:55 +0100 Do patches look ok to you? I'm travelling so I haven't looked closely yet :-) Michael can take a look and I'll try to do so as well tonight. Good. I plan to use gzip compression on following drivers' firmware, if patches will be accepted: textdata bss dec hex filename 17653 109968 240 127861 1f375 drivers/net/acenic.o 6628 120448 4 127080 1f068 drivers/net/dgrs.o ^^ -- vda - 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 1/2] bnx2: factor out gzip unpacker
On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said: I plan to use gzip compression on following drivers' firmware, if patches will be accepted: textdata bss dec hex filename 17653 109968 240 127861 1f375 drivers/net/acenic.o 6628 120448 4 127080 1f068 drivers/net/dgrs.o ^^ Should this be redone to use the existing firmware loading framework to load the firmware instead? pgpxgDFRcCcpF.pgp Description: PGP signature
Re: [PATCH 1/2] bnx2: factor out gzip unpacker
On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote: On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said: I plan to use gzip compression on following drivers' firmware, if patches will be accepted: textdata bss dec hex filename 17653 109968 240 127861 1f375 drivers/net/acenic.o 6628 120448 4 127080 1f068 drivers/net/dgrs.o ^^ Should this be redone to use the existing firmware loading framework to load the firmware instead? Not in every case. For example, bnx2 maintainer says that driver and firmware are closely tied for his driver. IOW: you upgrade kernel and your NIC is not working anymore. Another argument is to make kernel be able to bring up NICs without needing firmware images in initramfs/initrd/hard drive. -- vda - 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 1/2] bnx2: factor out gzip unpacker
On Fri, 21 Sep 2007 20:18:06 BST, Denys Vlasenko said: On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote: Should this be redone to use the existing firmware loading framework to load the firmware instead? Not in every case. For example, bnx2 maintainer says that driver and firmware are closely tied for his driver. IOW: you upgrade kernel and your NIC is not working anymore. Another argument is to make kernel be able to bring up NICs without needing firmware images in initramfs/initrd/hard drive. OK, I can live with considered and decided against. :) pgpQ8Dn8OWNLy.pgp Description: PGP signature
Re: [PATCH 1/2] bnx2: factor out gzip unpacker
Denys Vlasenko [EMAIL PROTECTED] writes: I plan to use gzip compression on following drivers' firmware, if patches will be accepted: textdata bss dec hex filename 17653 109968 240 127861 1f375 drivers/net/acenic.o 6628 120448 4 127080 1f068 drivers/net/dgrs.o ^^ Just change the makefiles to always install gzip'ed modules modutils knows how to unzip them on the fly. That will catch all the firmware and all the other code too. -Andi - 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 1/2] bnx2: factor out gzip unpacker
On Fri, 21 Sep 2007, Denys Vlasenko wrote: On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote: On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said: I plan to use gzip compression on following drivers' firmware, if patches will be accepted: textdata bss dec hex filename 17653 109968 240 127861 1f375 drivers/net/acenic.o 6628 120448 4 127080 1f068 drivers/net/dgrs.o ^^ Should this be redone to use the existing firmware loading framework to load the firmware instead? Not in every case. For example, bnx2 maintainer says that driver and firmware are closely tied for his driver. IOW: you upgrade kernel and your NIC is not working anymore. Firmware may come with a kernel. We have a install modules, we can also add install firmware. Another argument is to make kernel be able to bring up NICs without needing firmware images in initramfs/initrd/hard drive. It is not possible to bring up things like FC or WiFi without firmware, what special is in classic NICs? Best regards, Krzysztof Olędzki
Re: [PATCH 1/2] bnx2: factor out gzip unpacker
Just change the makefiles to always install gzip'ed modules modutils knows how to unzip them on the fly. But that leaves the uncompressed firmware blobs in .data that ends up in unswappable kernel memory. - R. - 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 1/2] bnx2: factor out gzip unpacker
For example, bnx2 maintainer says that driver and firmware are closely tied for his driver. IOW: you upgrade kernel and your NIC is not working anymore. Another argument is to make kernel be able to bring up NICs without needing firmware images in initramfs/initrd/hard drive. dgrs should be using the request_firmware interface. Actually dgrs is probably a good candidate for /dev/null Alan - 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 1/2] bnx2: factor out gzip unpacker
Alan Cox wrote: For example, bnx2 maintainer says that driver and firmware are closely tied for his driver. IOW: you upgrade kernel and your NIC is not working anymore. Another argument is to make kernel be able to bring up NICs without needing firmware images in initramfs/initrd/hard drive. dgrs should be using the request_firmware interface. Actually dgrs is probably a good candidate for /dev/null According to an earlier thread, dgrs was never really maintained, written for hardware that was never really distributed widely, and very likely hasn't had users in years... if ever. If that picture is accurate (it's a story I was told), then I am definitely queueing up a deletion patch. Jeff - 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 1/2] bnx2: factor out gzip unpacker
On Friday 21 September 2007 21:13, Andi Kleen wrote: Denys Vlasenko [EMAIL PROTECTED] writes: I plan to use gzip compression on following drivers' firmware, if patches will be accepted: textdata bss dec hex filename 17653 109968 240 127861 1f375 drivers/net/acenic.o 6628 120448 4 127080 1f068 drivers/net/dgrs.o ^^ Just change the makefiles to always install gzip'ed modules modutils knows how to unzip them on the fly. But I compile net/* into bzImage. I like netbooting :) -- vda - 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 1/2] bnx2: factor out gzip unpacker
According to an earlier thread, dgrs was never really maintained, written for hardware that was never really distributed widely, and very likely hasn't had users in years... if ever. If that picture is accurate (it's a story I was told), then I am definitely queueing up a deletion patch. I think thats sensible. If someone whines it can be put back but I really don't think anyone will - 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 1/2] bnx2: factor out gzip unpacker
On Friday 21 September 2007 20:33, Krzysztof Oledzki wrote: On Fri, 21 Sep 2007, Denys Vlasenko wrote: On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote: On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said: I plan to use gzip compression on following drivers' firmware, if patches will be accepted: textdata bss dec hex filename 17653 109968 240 127861 1f375 drivers/net/acenic.o 6628 120448 4 127080 1f068 drivers/net/dgrs.o ^^ Should this be redone to use the existing firmware loading framework to load the firmware instead? Not in every case. For example, bnx2 maintainer says that driver and firmware are closely tied for his driver. IOW: you upgrade kernel and your NIC is not working anymore. Firmware may come with a kernel. We have a install modules, we can also add install firmware. Install where? I boot my machine over NFS, and it has no hard drive. Another argument is to make kernel be able to bring up NICs without needing firmware images in initramfs/initrd/hard drive. It is not possible to bring up things like FC or WiFi without firmware, what special is in classic NICs? Nothing. It is just not (yet?) decreed from The Very Top that all and every firmware image should be loaded using request_firmware(). Also people may want to gzip something else than firmware. -- vda - 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 1/2] bnx2: factor out gzip unpacker
Denys Vlasenko wrote: On Friday 21 September 2007 20:33, Krzysztof Oledzki wrote: On Fri, 21 Sep 2007, Denys Vlasenko wrote: On Friday 21 September 2007 19:36, [EMAIL PROTECTED] wrote: On Fri, 21 Sep 2007 19:05:23 BST, Denys Vlasenko said: I plan to use gzip compression on following drivers' firmware, if patches will be accepted: textdata bss dec hex filename 17653 109968 240 127861 1f375 drivers/net/acenic.o 6628 120448 4 127080 1f068 drivers/net/dgrs.o ^^ Should this be redone to use the existing firmware loading framework to load the firmware instead? Not in every case. For example, bnx2 maintainer says that driver and firmware are closely tied for his driver. IOW: you upgrade kernel and your NIC is not working anymore. Firmware may come with a kernel. We have a install modules, we can also add install firmware. Install where? I boot my machine over NFS, and it has no hard drive. Special cases already fail when using distro-linked targets like make install. Jeff - 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 1/2] bnx2: factor out gzip unpacker
On Fri, Sep 21, 2007 at 11:48:05PM +0100, Alan Cox wrote: According to an earlier thread, dgrs was never really maintained, written for hardware that was never really distributed widely, and very likely hasn't had users in years... if ever. If that picture is accurate (it's a story I was told), then I am definitely queueing up a deletion patch. I think thats sensible. If someone whines it can be put back but I really don't think anyone will nobody did yet, please yell if you need a rebased patch. -- maks - 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 1/2] bnx2: factor out gzip unpacker
On Fri, 2007-09-21 at 10:49 -0700, David Miller wrote: From: Denys Vlasenko [EMAIL PROTECTED] Date: Fri, 21 Sep 2007 18:03:55 +0100 Do patches look ok to you? I'm travelling so I haven't looked closely yet :-) Michael can take a look and I'll try to do so as well tonight. I've already reviewed the earlier versions of the patch and have made some suggestions. This latest one looks ok to me and tested ok. I'll follow up later with another patch to remove all the zeros in other firmware sections, and to remove the gzip headers completely. Acked-by: Michael Chan [EMAIL PROTECTED] - 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/
