[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#509646: bnx2x firmware licensing



On Tue, Mar 31, 2009 at 05:31:03PM +0300, Eilon Greenstein wrote:
> On Mon, 2009-03-30 at 13:30 -0700, John Wright wrote:
> Hi John,
> > > 
> > > You are right - I'm adding a licensing to bnx2x_init_values.h similar
> > > to the bnx2 license that you quoted. However, I'm not sure if now is a
> > > good time to send such a patch to netdev for net-2.6 so I'm sending it
> > > to net-next - please let me know if this is not enough.
> > 
> > Thanks!  I'm now cleaning up the request_firmware patch to submit
> > upstream.  Is the init_ops array part of the firmware data derived from
> > proprietary unpublished source code, or may I take that to be in its
> > preferred form for modification?
> 
> The majority part of the init_ops derives from firmware proprietary
> unpublished source code - however, it was merged between the two chips
> (E1 and E1H) to reduce some code size (~1000 lines). We can split it
> again between the two chips and have a file per chip if that seems
> reasonable - the downside is that we will have about 1000 duplicated
> lines of (mostly meaningless) registers initializations.
> 
> If this is the way we want to go, I can work on creating the two files.
> What is the timeframe over here? When is the next deadline and when is
> the one after that...?

I was afraid of that...  It just makes the firmware logic more
complicated, since the firmware image also needs to keep track of the
function offsets in the init_ops array, which are currently just
#defines in the header.

I'm not sure there's any particular deadline -- I would like to see this
upstream soon so that Debian users can use bnx2x cards without building
a new kernel (and without having to maintain a patch in Debian's kernel
that won't go upstream).  For now, the initial split could keep init_ops
in a separate firmware file from the E1 and E1H specific blobs.  This
would result in 3 firmware files instead of bnx2x_init_values.h, and
the driver loading the init_ops file plus the E1 or E1H specific file at
init time.

I'll start figuring out how to store init_ops and the function offsets
in the firmware file.

-- 
John Wright <jsw@debian.org>



Reply to: