Qlogic/FC firmware

Qlogic/FC firmware

[David S. Miller]

Who removed it from the 2.4.x driver recently, and why?

I've been playing around, accidently corrupting my firmware
a few times, and had to grab the firmware back from older
trees to make my qlogic,FC card usable again.

Removing the firmware makes no sense, if the firmware was
incorrect for some reason, simply correct it.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "David" == David S Miller <davem@redhat.com> writes:

David> Who removed it from the 2.4.x driver recently, and why?

David> I've been playing around, accidently corrupting my firmware a
David> few times, and had to grab the firmware back from older trees
David> to make my qlogic,FC card usable again.

David> Removing the firmware makes no sense, if the firmware was
David> incorrect for some reason, simply correct it.

Alan did after I pointed out to him that it was incompatible with the
GPL (BSD license with advertisement clause). Really hard to fix unless
you get QLogic to change the license for you.

Jes

Re: Qlogic/FC firmware

[Alan Cox]

> Alan did after I pointed out to him that it was incompatible with the
> GPL (BSD license with advertisement clause). Really hard to fix unless
> you get QLogic to change the license for you.

Also the firmware we were including was seriously out of date, was a 
release candidate (not a certified release) and took up tons of ram

Re: Qlogic/FC firmware

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Tue, 21 Aug 2001 14:44:16 +0100 (BST)

   Also the firmware we were including was seriously out of date, was a 
   release candidate (not a certified release) and took up tons of ram

In many cases the driver worked before, and fails to work afterwards.

I still contend that the whole driver should have been lifted
instead of leaving a crippled version there.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[David S. Miller]

   From: Jes Sorensen <jes@sunsite.dk>
   Date: 21 Aug 2001 15:31:05 +0200
   
   Alan did after I pointed out to him that it was incompatible with the
   GPL (BSD license with advertisement clause). Really hard to fix unless
   you get QLogic to change the license for you.

And what about the Qlogic,ISP firmware in the tree too?  Those have no
copyright notice, but I think this is due to omission.  The same
identical firmware code in Matt Jacob's isp_dist.tar.gz driver has the
BSD license at the top of every firmware file.

You might as well remove all of these drivers in whole, as they are
basically non-functional without the accompanying firmware.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "David" == David S Miller <davem@redhat.com> writes:

David>    From: Jes Sorensen <jes@sunsite.dk> Date: 21 Aug 2001
David> 15:31:05 +0200
   
>    Alan did after I pointed out to him that it was incompatible
> with the GPL (BSD license with advertisement clause). Really
> hard to fix unless you get QLogic to change the license for
> you.

David> And what about the Qlogic,ISP firmware in the tree too?  Those
David> have no copyright notice, but I think this is due to omission.
David> The same identical firmware code in Matt Jacob's
David> isp_dist.tar.gz driver has the BSD license at the top of every
David> firmware file.

I have no idea where that firmware comes from. Since QLogic has in
fact re-released some of their firmware images under the GPL I have no
reason to believe images without copyright messages are in violation
of the BSD license.

If you have evidence that the isp driver ships with firmware thats in
violation of the GPL, then please remove it as well.

David> You might as well remove all of these drivers in whole, as they
David> are basically non-functional without the accompanying firmware.

So you are suggesting that we keep violating the GPL in order to help
out people nuking their own flash by mistake?

The much cleaner way to solve this problem is to write a user space
tool to upgrade the image in the flash ram on the QL with your latest
favorite image found at www.qlogic.com. It's a 128KB image, you can
write directly to the flash in two banks by setting the read/write bit
and setting the 2nd bank bit for the last 64KB.

Jes

Re: Qlogic/FC firmware

[David S. Miller]

   From: Jes Sorensen <jes@sunsite.dk>
   Date: 21 Aug 2001 15:51:55 +0200
   
   The much cleaner way to solve this problem is to write a user space
   tool to upgrade the image in the flash ram on the QL with your latest
   favorite image found at www.qlogic.com. It's a 128KB image, you can
   write directly to the flash in two banks by setting the read/write bit
   and setting the 2nd bank bit for the last 64KB.

When the Qlogic,FC sees a master abort, the firmware is essentially
cleared to zero.

This is what was happening to me.

Now what if I cannot boot now because this was on my root block
device.  I cannot even go back to a previous rev of the kernel
I was working on to get it back.

If you're going to say "put the user thing in initrd", I'm going to
say "bite me".  I build a static kernel with no initrd and that is how
I'd like it to stay.  It is one thing to do initrd firmware loading
for devices not necessary for booting and mounting root, that is
acceptable, this isn't.

Jes, I think your arguments are wrong.  I think the driver should
have been removed in whole and replaced with something like this
in qlogicfc.c so everyone would know what the problem is:

/* This driver was removed due to licensing in the firmware
 * which conflicts with the GPL.  The driver is only really
 * fully functional with the firmware included, so instead of
 * breaking half of the qlogic/fc users out there we removed
 * this driver outright.
 */

I would have never sent out the email which started this thread
had this been done.  I would not have questioned anything, and
would have instead said "unfortunate" to myself and left it at
that.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "David" == David S Miller <davem@redhat.com> writes:

David>    From: Jes Sorensen <jes@sunsite.dk> Date: 21 Aug 2001
David> 15:51:55 +0200
   
>    The much cleaner way to solve this problem is to write a
> user space tool to upgrade the image in the flash ram on the QL
> with your latest favorite image found at www.qlogic.com. It's a
> 128KB image, you can write directly to the flash in two banks
> by setting the read/write bit and setting the 2nd bank bit for
> the last 64KB.

David> When the Qlogic,FC sees a master abort, the firmware is
David> essentially cleared to zero.

David> This is what was happening to me.

Ehm, isn't the firmware only cleared to zero in the runtime memory or
are you saying that they nuke their flash ram as well? If the flash
ram is safe, you should still be able to boot any kernel and go from
there after you reset the adapter.

Clearing the firmware is still utterly stupid, but thats a firmware
stupidity. It is actually possibly to find the binary firmware image
out in the flash, but it's located at a weird location that makes me
suspect that they have some directory structure which I do not know
about.

David> If you're going to say "put the user thing in initrd", I'm
David> going to say "bite me".  I build a static kernel with no initrd
David> and that is how I'd like it to stay.  It is one thing to do
David> initrd firmware loading for devices not necessary for booting
David> and mounting root, that is acceptable, this isn't.

Well I thought Linus said we were going to have a required init
ramdisk for 2.5 anyway. But thats of course an unknown amount of time
away.

David> Jes, I think your arguments are wrong.  I think the driver
David> should have been removed in whole and replaced with something
David> like this in qlogicfc.c so everyone would know what the problem
David> is:

I disagree, the driver will still work just fine for people who have
the cards in machines such as PCs. I do agree however that it would
probably have been a good idea to leave a note in there stating why it
was removed.

However the reason I barked was because of you suggesting we remove
all firmware or should just have left it in there. If we have a GPL
violation then IMHO it has to be dealt with immediately, then we can
look at the damages afterwards.

Jes

Re: Qlogic/FC firmware

[David S. Miller]

   From: Jes Sorensen <jes@sunsite.dk>
   Date: 21 Aug 2001 16:28:09 +0200
   
   However the reason I barked was because of you suggesting we remove
   all firmware or should just have left it in there. If we have a GPL
   violation then IMHO it has to be dealt with immediately, then we can
   look at the damages afterwards.

Lack of copyright does not imply "do whatever you want with it".
The plain fact is that we don't know, and I'm trying to say
"it likely is a problem, let's go find out".

I think the QLogic,ISP driver firmware(s) being distributed is just as
serious an issue as the "obvious" qlogicfc_asm.c violation.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[Alan Cox]

> You might as well remove all of these drivers in whole, as they are
> basically non-functional without the accompanying firmware.

Now you are talking complete and total crap. I tested this firmware removal
stuff on a QlogicFC 2100 card. It works fine and I am now getting to use
the qualified firmware in the BIOS flash not the unqualified firmware in
the kernel.

Alan

Re: Qlogic/FC firmware

[Alan Cox]

> In many cases the driver worked before, and fails to work afterwards.
> I still contend that the whole driver should have been lifted
> instead of leaving a crippled version there.

Well now you know how everyone feels about the min() and max() changes.

However I _did_ test this, you can update the firmware in your BIOS flash
if you want a specific version and you have out of date firmwre currently
loaded.

Alan

Re: Qlogic/FC firmware

[Alan Cox]

> When the Qlogic,FC sees a master abort, the firmware is essentially
> cleared to zero.

None of the cards I have do this. Is this some kind of sparc specific
firmware problem ?

> If you're going to say "put the user thing in initrd", I'm going to
> say "bite me".  I build a static kernel with no initrd and that is how
> I'd like it to stay.  It is one thing to do initrd firmware loading
> for devices not necessary for booting and mounting root, that is
> acceptable, this isn't.

Why. What exactly is your argument ? Lets waste 128K of kernel space to keep
Dave happy. If the lack of proper boot time init on the sparc64 platform is
causing more problems then copy the firmware image out of the BIOS into the
card if sparc64 is defined.

And an initrd is the right answer. You free up the 128K of wasted space
using it.

Alan

Re: Qlogic/FC firmware

[Alexander Viro]

On Tue, 21 Aug 2001, Alan Cox wrote:

> Why. What exactly is your argument ? Lets waste 128K of kernel space to keep
> Dave happy. If the lack of proper boot time init on the sparc64 platform is
> causing more problems then copy the firmware image out of the BIOS into the
> card if sparc64 is defined.
> 
> And an initrd is the right answer. You free up the 128K of wasted space
> using it.

initrd is the right answer to question "where can I find shitty code?"

Now, having firmware loaded from userland _is_ nice and sane, but we
need something better than initrd for that.

Re: Qlogic/FC firmware

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Tue, 21 Aug 2001 15:17:25 +0100 (BST)
   
   However I _did_ test this, you can update the firmware in your BIOS flash
   if you want a specific version and you have out of date firmwre currently
   loaded.

There is no BIOS flash on my machines (onboard controllers).  The
kernel driver must be where the firmware comes from to boot reliably.

You broke this driver on all of my systems having QLogic,FC onboard.
The next time I powercycle or there is a PCI master abort on that bus
segment, I will be without a bootable machine.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Tue, 21 Aug 2001 15:15:20 +0100 (BST)

   > You might as well remove all of these drivers in whole, as they are
   > basically non-functional without the accompanying firmware.
   
   Now you are talking complete and total crap. I tested this firmware removal
   stuff on a QlogicFC 2100 card. It works fine

It works fine in your x86-centric world, on your x86 BIOS card.
It breaks on every UltraSparc system I have with qlogic,fc onboard.
One powercycle or PCI master abort, and I am unbootable.

And I am the one talking crap? :-)

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[Rik van Riel]

On Tue, 21 Aug 2001, David S. Miller wrote:

> And I am the one talking crap? :-)

"All the world's a SPARC"

I guess using an initrd on these 0.3% of machines shouldn't
be too big a problem compared to violating the GPL and adding
to kernel bloat for everybody else.

cheers,

Rik
--
IA64: a worthy successor to i860.

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: Qlogic/FC firmware

[Alan Cox]

> I guess using an initrd on these 0.3% of machines shouldn't
> be too big a problem compared to violating the GPL and adding
> to kernel bloat for everybody else.

The license thing is a side issue. We have a sane relationship with Qlogic
so that can easily be dealt with. For 2.5 it definitely wants to be in
initrd-tng however

Re: Qlogic/FC firmware

[christophe barbé]

Le mar, 21 aoû 2001 17:30:46, Alan Cox a écrit :
> > I guess using an initrd on these 0.3% of machines shouldn't
> > be too big a problem compared to violating the GPL and adding
> > to kernel bloat for everybody else.
> 
> The license thing is a side issue. We have a sane relationship with
> Qlogic
> so that can easily be dealt with. For 2.5 it definitely wants to be in
> initrd-tng however

I'm afraid that I don't understand what you mean by "a sane relationship
with Qlogic".
If the relation between kernel hackers and qlogic is good, why we don't
have an uptodate firmware with IP support and without license issue ?

The initial reason behind the firmware drop was the license.
And now it's a waste of RAM.

A few times ago, Dmitry (I don't remember his name but If you want I can
find it) has proposed an update for this driver including twos uptodate
firmware (with and without IP support). He give us a link to a website to
upload his patches ( http://www.datafoundation.org/qlogicfc/ ) but now the
link is broken.
If you are interresting I should be able to find his patch on an old disk.

This update resolves nearly all my problems with the in-kernel one.

And IIRC the included firmwares has no BSD license (no license at all
IIRC).

Christophe

-- 
Christophe Barbé
Software Engineer - christophe.barbe@lineo.fr
Lineo France - Lineo High Availability Group
42-46, rue Médéric - 92110 Clichy - France
phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01
http://www.lineo.com

Re: Qlogic/FC firmware

[Ricky Beam]

On Tue, 21 Aug 2001, Rik van Riel wrote:
>I guess using an initrd on these 0.3% of machines shouldn't
>be too big a problem

Were's the initrd going to get the firmware?  It's not in the freakin' tree
anymore.  If I have to go download a firmware image and stick it in an
initrd, why the hell wouldn't I just plug it directly into the kernel?
It's *my* kernel.

> compared to violating the GPL

Oh for the love of God, will you people stop drooling over the fucking GPL?
It's *firmware*... it's just a bunch of bits.  It's *not* a program the
kernel executes.  It's just data. (__init_data to be exact.)

> and adding
>to kernel bloat for everybody else.

One man's bloat is another man's functionality.  Besides, it's got a hell of
a lot of company.  Ask yourself, will you miss 128_K_ in a machine with a
fiber channel card in it?  It "bloats" the kernel for people using that
hardware -- machines that don't need it can release it.

--Ricky

(If Sun would get off their ass(es) and support firewire, I'd stop using linux
 all together.  And before some smartass says they do, point to the ohci and
 sbp-2 drivers on the Solaris 8 Sparc CD.)

Re: Qlogic/FC firmware

[Alan Cox]

> Were's the initrd going to get the firmware?  It's not in the freakin' tree
> anymore.  If I have to go download a firmware image and stick it in an
> initrd, why the hell wouldn't I just plug it directly into the kernel?
> It's *my* kernel.

Well initrd is _user_ space so it probably gets them from user space tools.

> Oh for the love of God, will you people stop drooling over the fucking GPL?
> It's *firmware*... it's just a bunch of bits.  It's *not* a program the
> kernel executes.  It's just data. (__init_data to be exact.)

Look, if its not distributable then its no good to anyone.

> a lot of company.  Ask yourself, will you miss 128_K_ in a machine with a
> fiber channel card in it?  It "bloats" the kernel for people using that
> hardware -- machines that don't need it can release it.

Well maybe, and whats the right way to do that, oh my god I do believe its
an initrd.

Well well well

Alan

Re: Qlogic/FC firmware

[Ricky Beam]

On Tue, 21 Aug 2001, Alan Cox wrote:
>Look, if its not distributable then its no good to anyone.

Who said it wasn't distributable?  The license in the 2.4.5 file doesn't say
you cannot distribute it.  It doesn't even prevent you from sell it.  You have
to leave the notice intact and not use it as a means to attach the Qlogic
mark to any derived product.

Other than it's age, I see *zero* reason to remove it from the tree.

>Well maybe, and whats the right way to do that, oh my god I do believe its
>an initrd.

__init_data

--Ricky

Re: Qlogic/FC firmware

[Alan Cox]

> On Tue, 21 Aug 2001, Alan Cox wrote:
> >Look, if its not distributable then its no good to anyone.
> 
> Who said it wasn't distributable?  The license in the 2.4.5 file doesn't say
> you cannot distribute it.  It doesn't even prevent you from sell it.  You have
> to leave the notice intact and not use it as a means to attach the Qlogic
> mark to any derived product.

 * 2. Redistribution in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.

Which is a problem because the kernel is GPL, that isnt GPL compatible
and until this was pointed out nobody has been going to print their blurb
in all the manuals - because after all it says GPL.

Licenses cannot be ignored. If I merge non GPL compliant code I'm doing to
the contributors to the kernel the very same thing people pirating windows
do to microsoft. 

> Other than it's age, I see *zero* reason to remove it from the tree.

Well let me quote from it again

/*
 *     W     W     A     RRRR    N   N   IIIII   N   N    GGG
 *     W     W    A A    R   R   N   N     I     N   N   G   G
 *     W     W   A   A   R  R    NN  N     I     NN  N   G  
 *     W  W  W   AAAAA   RRR     N N N     I     N N N   G  GG
 *     W  W  W   A   A   R R     N  NN     I     N  NN   G   G
 *     W W W W   A   A   R  R    N   N     I     N   N   G   G
 *      W   W    A   A   R   R   N   N   IIIII   N   N    GGGG
 *
 *         This version of firmware is a release candidate,
 *     design verification testing (DVT) has not been completed.
 */

or in simple terms "might lose all your data"

> >Well maybe, and whats the right way to do that, oh my god I do believe its
> >an initrd.
> 
> __init_data

Doesnt work in modules. See previous twice repeated discussion. 

As Matthew has noted, we have a source of newer firmware, and because the
sparc's have this annoying firmware problem it is going to be appropriate
to add build in firmware as a config option (probably set with def_bool on
sparc..)

At the time a) I didnt realise the sparc setup was so anal, and b) I didnt
know about the firmware update.

Alan

Re: Qlogic/FC firmware

[Matthew Jacob]

> > Other than it's age, I see *zero* reason to remove it from the tree.
>
> Well let me quote from it again
>
> /*
>  *     W     W     A     RRRR    N   N   IIIII   N   N    GGG
>  *     W     W    A A    R   R   N   N     I     N   N   G   G
>  *     W     W   A   A   R  R    NN  N     I     NN  N   G
>  *     W  W  W   AAAAA   RRR     N N N     I     N N N   G  GG
>  *     W  W  W   A   A   R R     N  NN     I     N  NN   G   G
>  *     W W W W   A   A   R  R    N   N     I     N   N   G   G
>  *      W   W    A   A   R   R   N   N   IIIII   N   N    GGGG
>  *
>  *         This version of firmware is a release candidate,
>  *     design verification testing (DVT) has not been completed.
>  */
>
> or in simple terms "might lose all your data"

Take this with a grain of salt. It's true that it hasn't passed DVT. But it's
also true that f/w which *has* passed DVT has eaten your data as well.

Almost precisely by definition, if the system you embed this firmware in is
*not* one that has gone thru Qlogic DVT, you should in fact be putting the
warning on yourself.

>
> > >Well maybe, and whats the right way to do that, oh my god I do believe its
> > >an initrd.
> >
> > __init_data
>
> Doesnt work in modules. See previous twice repeated discussion.
>
> As Matthew has noted, we have a source of newer firmware, and because the
> sparc's have this annoying firmware problem it is going to be appropriate
> to add build in firmware as a config option (probably set with def_bool on
> sparc..)
>
> At the time a) I didnt realise the sparc setup was so anal, and b) I didnt
> know about the firmware update.
>

It's not just a question of having firmware updated into flash- which, btw,
companies like Veritas have shied away from getting custoemrs to do because
you *do* have a small but finite amount of risk updating flash. It's also code
that as yet has to be written for qlogicfc (e.g.) that would pull it *out* of
flash so it can be pushed into SRAM (which is what the BIOS code on other
platforms do).

-matt

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "Matthew" == Matthew Jacob <mjacob@feral.com> writes:

Matthew> It's not just a question of having firmware updated into
Matthew> flash- which, btw, companies like Veritas have shied away
Matthew> from getting custoemrs to do because you *do* have a small
Matthew> but finite amount of risk updating flash. It's also code that
Matthew> as yet has to be written for qlogicfc (e.g.) that would pull
Matthew> it *out* of flash so it can be pushed into SRAM (which is
Matthew> what the BIOS code on other platforms do).

Yeah vendors tend to like this idea, it's not just Veritas and QLogic
who went down this path, unfortunately.

Updating the flash does seem very easy, and the good thing about the
QLA adapters is that you can reflash even if you screwed up in the
first place. Yup I tried that ;) Writing the flash utility seems like
a piece of cake in this as well. What doesn't look as easy is to
figure out that directory structure of the firmware images ;-( Any
chance you got some data on that?

Cheers,
Jes

Re: Qlogic/FC firmware

[Matthew Jacob]

> >>>>> "Matthew" == Matthew Jacob <mjacob@feral.com> writes:
>
> Matthew> It's not just a question of having firmware updated into
> Matthew> flash- which, btw, companies like Veritas have shied away
> Matthew> from getting custoemrs to do because you *do* have a small
> Matthew> but finite amount of risk updating flash. It's also code that
> Matthew> as yet has to be written for qlogicfc (e.g.) that would pull
> Matthew> it *out* of flash so it can be pushed into SRAM (which is
> Matthew> what the BIOS code on other platforms do).
>
> Yeah vendors tend to like this idea, it's not just Veritas and QLogic
> who went down this path, unfortunately.
>
> Updating the flash does seem very easy, and the good thing about the QLA
> adapters is that you can reflash even if you screwed up in the first
> place. Yup I tried that ;) Writing the flash utility seems like a piece of
> cake in this as well. What doesn't look as easy is to figure out that
> directory structure of the firmware images ;-( Any chance you got some
> data on that?

There are x86 utilities from Qlogic to *write* the flash. Reading the flash
isn't that hard itself. There is no documentation as to flash layout. Older
versions of the Linux driver say where they keep a copy of the current target
to WWN mapping in flash (which is a 'maybe not so bright' idea).

We could ask them where it is.

-matt

Re: Qlogic/FC firmware

[Matthew Jacob]

> We could ask them where it is.

I've asked their tech support folks about where and how big in flash the RISC
code is for all their cards. I have other people I can ask too. Let's see if
they're helpful or open about it.

I'm not as sensitive to the bloat issues as I should be- I suppose because I
tend to see all of USB as bloat myself :).. I tend to think that the generic
shipping kernel case should have all of the firmware images there to download
from the driver.

That said, it *would* be nice to give people some tools to strip things down
if they really want, out of a 2GB system, a couple hundred kbytes back that
can the be gobbled up by something really hungry for it like a memory leak in
X or Matzohilla or something :-)....

-matt

Re: Qlogic/FC firmware

[David S. Miller]

   From: Matthew Jacob <mjacob@feral.com>
   Date: Wed, 22 Aug 2001 09:17:07 -0700 (PDT)

   Matzohilla

You're such a nebbish Matt. :-)

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[Ricky Beam]

On Wed, 22 Aug 2001, Alan Cox wrote:
> * 2. Redistribution in binary form must reproduce the above copyright
> *    notice, this list of conditions and the following disclaimer in the
> *    documentation and/or other materials provided with the distribution.
>
>Which is a problem because the kernel is GPL, that isnt GPL compatible
>and until this was pointed out nobody has been going to print their blurb
>in all the manuals - because after all it says GPL.

The kernel source counts as "other materials".

>> Other than it's age, I see *zero* reason to remove it from the tree.
>
>Well let me quote from it again
...
>or in simple terms "might lose all your data"

Gee.  And how many installation have been running that firmware for how
many years without problems?  As I said before, other than it's age, there's
no reason to simply delete it.

>Doesnt work in modules. See previous twice repeated discussion.

We aren't talking about a module when it's compiled into the kernel.  In
the case(s) of modules, there are many ways to provide data (such as
firmware) without the aforementioned bloat everyone wants to bitch about.
And I'd like to point out the people screaming about bloat do not have
the hardware for which this driver is required and thusly will *never*
lose the coveted 128K for it's firmware.  There are areas of "bloat" with
far further reach than this.  Go get a few thousand signatures from actual
Qlogic FC owners running linux oking your destablization of the driver and
I'll leave this alone.  Otherwise, either delete the driver entirely or
put the firmware for which the driver is designed and proven stable by the
test of time back in the tree.

This is the 2.4 "stable" kernel tree.  One would assume people work towards
*increasing* it's stability by fixing its flaws, not wildly deleting shit
and (possibly) randomly breaking things. (But I digress.  I'm treading into
the abyss of source/configuration management of which the kernel tree has
none.)

>As Matthew has noted, we have a source of newer firmware, and because the
>sparc's have this annoying firmware problem it is going to be appropriate
>to add build in firmware as a config option (probably set with def_bool on
>sparc..)

As I recall, the Qlogic ISP driver has had a similar option for years.
(Maybe not to prevent compilation but certainly to prevent loading it.)

>At the time a) I didnt realise the sparc setup was so anal, and b) I didnt
>know about the firmware update.

So basically, you had no fucking clue what kind of instability you were about
to introduce into the current "stable" line of kernels, but did it anyway
simply because of the wording (and your interpretation thereof) of the license
on a firmware "data" file.  Wording that has been unchanged since the day
the file was entered into the tree.  If there were objections, questions,
or other concerns, they should have been raised then and not months or years
later.  And there should have been at least some discussion before removing
the file and seeing who notices. (If I missed this discussion, then I
apologize.)

--Ricky

Re: Qlogic/FC firmware

[Alan Cox]

> We aren't talking about a module when it's compiled into the kernel.  In
> the case(s) of modules, there are many ways to provide data (such as
> firmware) without the aforementioned bloat everyone wants to bitch about.

Like loading it from user space. Which is exactly the same code needed
for an initrd. Amazing isn it.

> And I'd like to point out the people screaming about bloat do not have
> the hardware for which this driver is required and thusly will *never*

Wrong. I object to wasting 128K and I have fibrechannel. Its that kind of
sloppy "who cares about 128K" thinking that leads to several megs
disappearing and your OS turning into sludge. 

> So basically, you had no fucking clue what kind of instability you were about
> to introduce into the current "stable" line of kernels, but did it anyway

It caused a trivial little problem for a few sparc people which basically has 
only been more than a

	"Hey Alan, sparc needs firmware compiled in can you fix"

because it seems you have to be arrogant and opinionated to own a sparc64
box 8)

> the file was entered into the tree.  If there were objections, questions,
> or other concerns, they should have been raised then and not months or years
> later.  And there should have been at least some discussion before removing

Take that one up with Linus. I didn't merge it originally

Alan

Re: Qlogic/FC firmware

[Ricky Beam]

On Wed, 22 Aug 2001, Alan Cox wrote:
>Like loading it from user space. Which is exactly the same code needed
>for an initrd. Amazing isn it.

Amazing *and* unnecessarily complex.  What a bargin!  And it's still going
to consume that precious 128K even when loaded from usersapce as the driver
will still need to keep it.  And aren't you one of the Preists of Text in
/proc -- those of the belief in managing everything with 'cat' and 'vi'.

>Wrong. I object to wasting 128K and I have fibrechannel. Its that kind of
>sloppy "who cares about 128K" thinking that leads to several megs
>disappearing and your OS turning into sludge.

Way too damn late make that argument.  That snowball has been gaining mass
and speed for years now.  I would not recommend standing in front of it.

>> So basically, you had no fucking clue what kind of instability you were about
>> to introduce into the current "stable" line of kernels, but did it anyway
>
>It caused a trivial little problem for a few sparc people which basically has
>only been more than a
>
>	"Hey Alan, sparc needs firmware compiled in can you fix"
>
>because it seems you have to be arrogant and opinionated to own a sparc64
>box 8)

I stand by my original "fucking" comment :-)  I wouldn't trivialize this
"little problem".  I'm guessing this is a problem for Alphas as well.  Altho'
Digital (now Compaq) doesn't call it a Qlogic,FC -- their naming scheme is
on par with Cisco -- it doesn't have any firmware on the card.  SRM loads
firmware on it to scan for devices.  Having a machine randomly crash for no
easily detectable reason (esp. if you log to FC) is not good.  In fact,
one may not notice the problem for some time.

Dave, what kind of messages does a master abort cause?

>> the file was entered into the tree.  If there were objections, questions,
>> or other concerns, they should have been raised then and not months or years
>> later.  And there should have been at least some discussion before removing
>
>Take that one up with Linus. I didn't merge it originally

No, you take it up with Linus (and the Qlogic maintainer) as you are the nut
removing it ... and introducing a great big question mark around the stability
of the Qlogic FC driver.

--Ricky

Re: Qlogic/FC firmware

[Alan Cox]

> Amazing *and* unnecessarily complex.  What a bargin!  And it's still going
> to consume that precious 128K even when loaded from usersapce as the driver
> will still need to keep it.  And aren't you one of the Preists of Text in

No. We can jettison it and you know that in fact you commented on using 
__initdata in the non modular case, so stop trolling and if you are going to
be a pain, at least be consistant in your arguments. 

> /proc -- those of the belief in managing everything with 'cat' and 'vi'.

No. That would be Al Viro. 

> >sloppy "who cares about 128K" thinking that leads to several megs
> >disappearing and your OS turning into sludge.
> 
> Way too damn late make that argument.  That snowball has been gaining mass
> and speed for years now.  I would not recommend standing in front of it.

If I was working on Irix maybe, but I'm not. I've got another .5Mb on my
256Mb box I want back in 2.5 as well 8)

> "little problem".  I'm guessing this is a problem for Alphas as well.  Altho'

Alpha's have x86 emulation in the boot loaders. Thats a not-nice solution to
most of the PC worlds evils but works out.

> >Take that one up with Linus. I didn't merge it originally
> 
> No, you take it up with Linus (and the Qlogic maintainer) as you are the nut
> removing it ... and introducing a great big question mark around the stability
> of the Qlogic FC driver.

See previous four conversations on this. Licensing matters. 

Case closed

Alan

Re: Qlogic/FC firmware

[Ricky Beam]

On Wed, 22 Aug 2001, Alan Cox wrote:
>> Amazing *and* unnecessarily complex.  What a bargin!  And it's still going
>> to consume that precious 128K even when loaded from usersapce as the driver
>> will still need to keep it.  And aren't you one of the Preists of Text in
>
>No. We can jettison it and you know that in fact you commented on using
>__initdata in the non modular case, so stop trolling and if you are going to
>be a pain, at least be consistant in your arguments.

I'm missing the "in the case of sparc" clause.  The sparc (and maybe others?)
have to keep the firmware image in memory in the case that it needs to reload
the sequencer.  The initrd simply adds more tool-chains to keep up-to-date.
Any distribution supporting the Qlogic,FC will have to supply a firmware file
in binary form to initialize the card.  And then you're right back to square
one in the binary distribution arena.

--Ricky

Re: Qlogic/FC firmware

[Alan Cox]

> I'm missing the "in the case of sparc" clause.  The sparc (and maybe others?)
> have to keep the firmware image in memory in the case that it needs to reload

Read the source code. The driver never reloads the firmware on a running
card. So if the sparc needed that it never worked anyway, and I don't follow
your argument.

If you do need to reload the firmware on real live sparc setups after driver
setup then someone needs to do some patching.

Unlike you, I actually read the source

Alan

Re: Qlogic/FC firmware

[Ricky Beam]

On Wed, 22 Aug 2001, Alan Cox wrote:
>Read the source code. The driver never reloads the firmware on a running
>card. So if the sparc needed that it never worked anyway, and I don't follow
>your argument.

If the card wasn't setup by the BIOS (OBP in the Sparc case), then the driver
won't work.  And as late as 2.4.8, RELOAD_FIRMWARE was set to '1'.  Gee,
look what was changed in 2.4.9:

--- v2.4.8/linux/drivers/scsi/qlogicfc.c        Sun Aug 12 13:28:00 2001
+++ linux/drivers/scsi/qlogicfc.c       Sun Aug 12 10:51:41 2001
@@ -98,7 +98,7 @@
    isp2200's firmware.
 */

-#define RELOAD_FIRMWARE                1
+#define RELOAD_FIRMWARE                0

 #define USE_NVRAM_DEFAULTS      1

@@ -440,7 +440,7 @@
 #define MBOX_SEND_CHANGE_REQUEST        0x0070
 #define MBOX_PORT_LOGOUT                0x0071

-#include "qlogicfc_asm.c"
+//#include "qlogicfc_asm.c"

(I will note, that's not even a valid C construct. '//' is a C++ism.)

>Unlike you, I actually read the source

So, was that before or after you removed the firmware? (And who says I don't
read source code?  That's the first place I go to find out who fucked up
what.  I'm running 2.4.5 and below.  The only thing I have running 2.4.9 is
my laptop, and that was a certified nightmare.)

--Ricky

Re: Qlogic/FC firmware

[Alan Cox]

> -#include "qlogicfc_asm.c"
> +//#include "qlogicfc_asm.c"
> 
> (I will note, that's not even a valid C construct. '//' is a C++ism.)

Your C standard is as out of date as your architecture ;)

Re: Qlogic/FC firmware

[David S. Miller]

   From: Ricky Beam <jfbeam@bluetopia.net>
   Date: Wed, 22 Aug 2001 14:46:27 -0400 (EDT)

   On Wed, 22 Aug 2001, Alan Cox wrote:
   >Read the source code. The driver never reloads the firmware on a running
   >card. So if the sparc needed that it never worked anyway, and I don't follow
   >your argument.
   
   If the card wasn't setup by the BIOS (OBP in the Sparc case), then the driver
   won't work.  And as late as 2.4.8, RELOAD_FIRMWARE was set to '1'.  Gee,
   look what was changed in 2.4.9:
   
Please read what people are saying.

He said "running card"  Which means that it does not handle the
PCI master case on a running system, which I never claimed it did.

The older code does guarentee that if I did powercycle and reboot
at that point, I will get a functional card back, which the current
code does not do.

Alan's actively trying to resolve this problem by getting usable
firmware from Qlogic.  What are you doing to improve the situation
besides trolling like made on this list?

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "Ricky" == Ricky Beam <jfbeam@bluetopia.net> writes:

Ricky> On Wed, 22 Aug 2001, Alan Cox wrote:
>>> the file was entered into the tree.  If there were objections,
>>> questions, or other concerns, they should have been raised then
>>> and not months or years later.  And there should have been at
>>> least some discussion before removing
>>  Take that one up with Linus. I didn't merge it originally

Ricky> No, you take it up with Linus (and the Qlogic maintainer) as
Ricky> you are the nut removing it ... and introducing a great big
Ricky> question mark around the stability of the Qlogic FC driver.

*plonk*

Jes

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "Ricky" == Ricky Beam <jfbeam@bluetopia.net> writes:

Ricky> On Wed, 22 Aug 2001, Alan Cox wrote:
>> At the time a) I didnt realise the sparc setup was so anal, and b)
>> I didnt know about the firmware update.

Ricky> So basically, you had no fucking clue what kind of instability
Ricky> you were about to introduce into the current "stable" line of
Ricky> kernels, but did it anyway simply because of the wording (and
Ricky> your interpretation thereof) of the license on a firmware
Ricky> "data" file.  Wording that has been unchanged since the day the
Ricky> file was entered into the tree.  If there were objections,
Ricky> questions, or other concerns, they should have been raised then
Ricky> and not months or years later.  And there should have been at
Ricky> least some discussion before removing the file and seeing who
Ricky> notices. (If I missed this discussion, then I apologize.)

Wording as interpreted by lawyers and anybody who is capable of
reading English.

As to your argument about raising the concerns when the thing went
in. We (as in the kernel developers) made a mistake, we noticed it we
fix it ... see it's really that simple.

Jes

Re: Qlogic/FC firmware

[Rik van Riel]

On Wed, 22 Aug 2001, Ricky Beam wrote:

> So basically, you had no fucking clue

Since you're the expert, why won't we all wait for
YOUR patch to fix the problem? ;)

Rik
--
IA64: a worthy successor to i860.

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: Qlogic/FC firmware

[Oliver Neukum]

> > Oh for the love of God, will you people stop drooling over the fucking
> > GPL? It's *firmware*... it's just a bunch of bits.  It's *not* a program
> > the kernel executes.  It's just data. (__init_data to be exact.)
>
> Look, if its not distributable then its no good to anyone.

Are you allowed to distribute an initrd that contains it, build from it and 
GNU tools ?

	Regards
		Oliver

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "Oliver" == Oliver Neukum <Oliver.Neukum@lrz.uni-muenchen.de> writes:

>> > Oh for the love of God, will you people stop drooling over the
>> fucking > GPL? It's *firmware*... it's just a bunch of bits.  It's
>> *not* a program > the kernel executes.  It's just
>> data. (__init_data to be exact.)
>> 
>> Look, if its not distributable then its no good to anyone.

Oliver> Are you allowed to distribute an initrd that contains it,
Oliver> build from it and GNU tools ?

If you don't violate any of the licenses of the apps you stick on the
initrd. The fact you use GNU tools to build the initrd doesn't really
matter.

The problem with including this in the kernel is that the kernel as a
whole is GPL'ed so including something that is in conflict with the
GPL is kinda problematic.

Cheers
Jes

Re: Qlogic/FC firmware

[Ricky Beam]

On Wed, 22 Aug 2001, Oliver Neukum wrote:
>> > Oh for the love of God, will you people stop drooling over the fucking
>> > GPL? It's *firmware*... it's just a bunch of bits.  It's *not* a program
>> > the kernel executes.  It's just data. (__init_data to be exact.)
>>
>> Look, if its not distributable then its no good to anyone.
>
>Are you allowed to distribute an initrd that contains it, build from it and
>GNU tools ?

Depends on who's interpreting the license.  I say as long as the source to
the whole mess is available (even provided *with* the binaries), you aren't
violating anything.  On the otherhand, strictly speaking, once the file
is compiled, it becomes "in binary form" which needs the notice attached to
it in some way -- like all the fine print one finds on any box of stuff from
Sun, Compaq/Digital, Cisco, etc.

However, as others have said, none of us are lawyers.  Of course, none of us
have been sued by Qlogic either.

--Ricky

Re: Qlogic/FC firmware

[Matthew Jacob]

> --Ricky
>
> (If Sun would get off their ass(es) and support firewire, I'd stop using linux
>  all together.  And before some smartass says they do, point to the ohci and
>  sbp-2 drivers on the Solaris 8 Sparc CD.)

Oh-yeah- the ones that cause panics when attached to USB multiport terminal
switch hubs?

Re: Qlogic/FC firmware

[Ricky Beam]

On Tue, 21 Aug 2001, Matthew Jacob wrote:
>Oh-yeah- the ones that cause panics when attached to USB multiport terminal
>switch hubs?

No, the non-existant ieee1394 (firewire) ones.  I refuse to by Sun hardware
with IDE and USB capability.

--Ricky

Re: Qlogic/FC firmware

[David S. Miller]

   From: Ricky Beam <jfbeam@bluetopia.net>
   Date: Tue, 21 Aug 2001 18:45:02 -0400 (EDT)
   
Re: GPL  It's a source file and it had a copyright at the top.
Regardless of what the contents mean, the copyright the author
put there has to be abided by.

   (If Sun would get off their ass(es) and support firewire, I'd stop using linux
    all together.  And before some smartass says they do, point to the ohci and
    sbp-2 drivers on the Solaris 8 Sparc CD.)

I normally chastise Sun just to get my jollies off, but this
is a too much of an untrue statement about them even for me
to tolerate.

Solaris-8 supports fully the ieee1394 interfaces on Ultra-III
machines just fine.  I don't know what the package name is, but
the kernel drivers are there in the SME hw releases done for
the Ultra-III.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[David S. Miller]

   From: Rik van Riel <riel@conectiva.com.br>
   Date: Tue, 21 Aug 2001 11:42:11 -0300 (BRST)
   
   I guess using an initrd on these 0.3% of machines shouldn't
   be too big a problem compared to violating the GPL and adding
   to kernel bloat for everybody else.

init_data the firmware, it isn't bloat.

The copyright is a totally seperate issue.

Later,
David S. Miller
davem@redhat.com
   

Re: Qlogic/FC firmware

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Tue, 21 Aug 2001 15:24:17 +0100 (BST)

   > When the Qlogic,FC sees a master abort, the firmware is essentially
   > cleared to zero.
   
   None of the cards I have do this. Is this some kind of sparc specific
   firmware problem ?

Without x86 BIOS this is the situation you will get.

Unless you tell the firmware to probe all scsi devices at the OBP
command line, there is no firmware loaded into the FC card.  There
is no reason for firmware to get loaded onto the card.

So if I boot kernels from the Symbios scsi device and use a disk
on my qlogic,fc as root, I am fucked after my next power cycle.
This is exactly my setup on one of my systems.
   
What other non-x86 systems trying to use QLogic/FC cards as root?
Such as PPC.  There is nothing wrong or stupid about this, and such
systems have been broken by removing the firmware.

   Why. What exactly is your argument ? Lets waste 128K of kernel space to keep
   Dave happy. If the lack of proper boot time init on the sparc64 platform is
   causing more problems then copy the firmware image out of the BIOS into the
   card if sparc64 is defined.
   
That would require that I know where in the forth image Sun
sticks the firmware, I have no way to figure this out except
by toiling over disassembler dumps of the cards firmware.

I have no guarentees even that this is where it is (in the PCI
ROM of the qlogic,fc card) they could have just as well have stuffed
it into some arbitrary place in the main system forth ROM.

   And an initrd is the right answer. You free up the 128K of wasted space
   using it.
   
I'd rather have 128k of wasted space than an unbootable system.

All of Matt Jacob's drivers include all the firmware.  And this
makes a lot of sense for another reason, QA.  If you know what
firmware rev. everyone is using, you don't have to second guess
bug reports by asking "oh and what firmware did the BIOS load onto
your card btw" each time.

Nobody, and I mean nobody, except Linux has a Qlogic,FC kernel driver
that fails to load a known version of the firmware.

Also, "128k of wasted space" is a bogus argument too.  If you
build it statically into the kernel, __init_data the firmware.
And when we have the initmem stuff working for modules again (Jakub
did this years ago) you'll get it free'd up for the non-static case
too.   Fix the problem, not a symptom.

If you had put something like "This driver removed due to copyright
problems" into qlogicfc.c then I would have had no problems.

But to see only the firmware disappear almost looked like a careless
merge error.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[Alan Cox]

> There is no BIOS flash on my machines (onboard controllers).  The
> kernel driver must be where the firmware comes from to boot reliably.

Ok so you have a sparc specific firmware loading problem. So IMHO the
right thing to do is to write a sparc specific firmware loader - either
as a module living in arch/sparc64 or assuming you never need to reload
the firmware past boot - use an initrd

For the other 99.9% of the userbase we saved 128Kbytes of ram and improved
reliability by not loading half tested firmeware on them.

Alan

Re: Qlogic/FC firmware

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Tue, 21 Aug 2001 15:45:26 +0100 (BST)
   
   For the other 99.9% of the userbase we saved 128Kbytes of ram and improved
   reliability by not loading half tested firmeware on them.

We saved nothing, __init_data the firmware, problem solved.

If the firmware was out of date, update it to a known "Qlogic stamp of
approval" version.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Tue, 21 Aug 2001 15:45:26 +0100 (BST)
   
   Ok so you have a sparc specific firmware loading problem.

No, it is a non-x86 firmware loading problem.  Do not label
it is as a "all the world a Sparc" problem, it isn't centric
to any particular platform.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "David" == David S Miller <davem@redhat.com> writes:

David>    From: Alan Cox <alan@lxorguk.ukuu.org.uk> Date: Tue, 21 Aug
David> 2001 15:45:26 +0100 (BST)
   
>    Ok so you have a sparc specific firmware loading problem.

David> No, it is a non-x86 firmware loading problem.  Do not label it
David> is as a "all the world a Sparc" problem, it isn't centric to
David> any particular platform.

It's centric to a limited userbase, other systems such as Alpha and
ia64 can load the firmware off the cards no problem.

Doesn't mean we have solved your problem, true. But initrd is still a
cleaner solution and gets around the licensing problem as well.

Jes

Re: Qlogic/FC firmware

[Alan Cox]

> We saved nothing, __init_data the firmware, problem solved.

Except when its modular, as in 99% of distro kernels

> If the firmware was out of date, update it to a known "Qlogic stamp of
> approval" version.

That requires sorting licensing out with Qlogic. I've talked to them
usefully about other stuff so I'll pursue it for a seperate firmware
loader module.

Alan

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>> If the firmware was out of date, update it to a known "Qlogic stamp
>> of approval" version.

Alan> That requires sorting licensing out with Qlogic. I've talked to
Alan> them usefully about other stuff so I'll pursue it for a seperate
Alan> firmware loader module.

Well getting firmware out of them tends to be up and down.

However I just looked through the QLogic v4.27 provided driver from
their web site and it does in fact included firmware with a GPL
license.

Dave, if you want to play with this and stick it into the qlogicfc.c
driver then you will at least have something that sorta works for now
(module all the other problems with that driver).

http://www.qlogic.com/bbs-html/csg_web/adapter_pages/driver_pages/22xx/22linux.html

They do have a stupid 'read and agree' license in front of that page
if you go in via the official qlogic.com door, however if the code
inside is GPL then I asume it's GPL.

Cheers
Jes

Re: Qlogic/FC firmware

[Alan Cox]

> 
> >>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> 
> >> If the firmware was out of date, update it to a known "Qlogic stamp
> >> of approval" version.
> 
> Alan> That requires sorting licensing out with Qlogic. I've talked to
> Alan> them usefully about other stuff so I'll pursue it for a seperate
> Alan> firmware loader module.
> 
> Well getting firmware out of them tends to be up and down.
> 
> However I just looked through the QLogic v4.27 provided driver from
> their web site and it does in fact included firmware with a GPL
> license.
> 
> Dave, if you want to play with this and stick it into the qlogicfc.c
> driver then you will at least have something that sorta works for now
> (module all the other problems with that driver).
> 
> http://www.qlogic.com/bbs-html/csg_web/adapter_pages/driver_pages/22xx/22linux.html
> 
> They do have a stupid 'read and agree' license in front of that page
> if you go in via the official qlogic.com door, however if the code
> inside is GPL then I asume it's GPL.
> 
> Cheers
> Jes
> 

Re: Qlogic/FC firmware

[Matthew Jacob]

On Tue, 21 Aug 2001, Alan Cox wrote:

> >
> > >>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> >
> > >> If the firmware was out of date, update it to a known "Qlogic stamp
> > >> of approval" version.
> >
> > Alan> That requires sorting licensing out with Qlogic. I've talked to
> > Alan> them usefully about other stuff so I'll pursue it for a seperate
> > Alan> firmware loader module.
> >
> > Well getting firmware out of them tends to be up and down.
> >
> > However I just looked through the QLogic v4.27 provided driver from
> > their web site and it does in fact included firmware with a GPL
> > license.

Interesting- I should have checked- they didn't use to have GPL on the f/w.
Earlier driver versions didn't! Oops!

-matt

Re: Qlogic/FC firmware

[Matthew Jacob]

>
> Interesting- I should have checked- they didn't use to have GPL on the f/w.
> Earlier driver versions didn't! Oops!
>

Actually, it's not quite. The 2200 f/w has:

/************************************************************************
 *                                                                      *
 *               --- ISP2200 Initiator/Target Firmware ---              *
 *             with Fabric (Public Loop), Point-point, and              *
 *             expanded LUN addressing for FCTAPE                       *
 *                                                                      *
 ************************************************************************
  Copyright (C) 2000 and 2100 Qlogic Corporation
  (www.qlogic.com)

  This program is distributed in the hope that it will be useful, but
  WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  General Public License for more details.
*******************************************************************
/*
 *      Firmware Version 2.01.27 (11:07 Dec 18, 2000)
 */

(you should  note, btw, that the f/w that's on the internal QLogic website for
OEMS is 2.1.26)

So, it's *sort of* GPLd....

-matt

Re: Qlogic/FC firmware

[Alan Cox]

> However I just looked through the QLogic v4.27 provided driver from
> their web site and it does in fact included firmware with a GPL
> license.

Yep. How has getting them to take updates to their 'official driver' been
going btw

Alan

Re: Qlogic/FC firmware

[David S. Miller]

   From: Jes Sorensen <jes@sunsite.dk>
   Date: 21 Aug 2001 18:39:04 +0200
   
   Dave, if you want to play with this and stick it into the qlogicfc.c

None of this topic matters at all for me.  I
just cvs co -date foo qlogicfc_asm.c and edit
qlogicfc.c to include and use it again :-)

It's more important for others people.

If the firmware you point to is indeed suitably licensed, we should
put it into the tree.  If what you're asking me to do is take care
of this, no problem.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic/FC firmware

[Matthew Jacob]

A few of pieces of information and comments:

The "BSD" copyright in the f/w I have from QLogic is there only because Theo
Deraadt threatened to pull QLogic from the 2.7 OpenBSD release. I'd been
pleading with them for over a year to do *something*. I should have done a BSD
license w/o the advert clause, but, oh, well.....

To understand what shape you're in, it's really best to load firmware into the
card's SRAM. That way you *know* it understands feature foo (like SCCLUN, for
example). QLogic produces so many different flavors of firmware of the same
nominal revision that it's hard to deduce the viability or safety of some
firmware.

That said, it *is* possible in a non-BIOS environment to pull firmware out of
flash rom, I believe- you have to do some hand strobing of registers that
normally only the firmware touches, but I think it *is* technically possible
to pull the contents of flash out into system memory, figure out where the
'resident' f/w image is in this goop and then download *that* into SRAM and
restart the sequencer. Still- this leaves you in the same position as before.

IMO, the best thing is to do an ispfw load module that goes away after you've
loaded SRAM. I've started down this path in FreeBSD (there's a separate ispfw
module)- which will only be really useful if module memory ever gets reclaimed
in FreeBSD :-). This is of particular importance for my driver, because in
supporting 1020 (SBus (yes for NetBSD/OpenBSD, not yet for Linux)  && PCI),
1080/1280 Ultra2, 12160 Ultra3, 2100 FC, 2200FC and 2300FC (next week)- you
end up with an absurd amount of f/w images.

I'm sure there's something similar that can be done for Linux.

Alan- you say you can talk to QLogic- good. I've been finding it harder and
harder to talk to them. If you can get them to put out 2100 and 2200 and 2300
f/w with GPL for Linux- great.

-matt

Re: Qlogic/FC firmware

[Jes Sorensen]

>>>>> "David" == David S Miller <davem@redhat.com> writes:

David> If the firmware you point to is indeed suitably licensed, we
David> should put it into the tree.  If what you're asking me to do is
David> take care of this, no problem.

Well I was offering you a solution to your problem. Whether you want
to take it or not is really up to you. I can live with the driver not
shipping any firmware image, but it sounds like Sparc users can't.

Jes