Re: integration of opensource firmware with b43 kernel driver

[Michael Buesch <mb@bu3sch.de>]

On Friday 23 January 2009 20:18:52 Francesco Gringoli wrote:
> > Nothing. Why do we need to have different names?
> Well, I was only considering a question raised by John, we can surely  
> maintain these names.

I guess I missed that. What was the question?
Note that proprietary and open firmwares are in separate directories, so
I don't see why we should rename them.
Renaming firmware is a huge pain. We did it several times in the past and
I really want to avoid it. It creates a major confusion for users for some months.

> >> - detection of the opensource firmware capabilities: are you really
> >> sure we cannot use a shm location that the bcm proprietary firmware
> >> uses for some other purpose?
> >
> > Yes, well. You're not intermixing an earlier discussion into this,  
> > where
> > you didn't indicate opensource capabilities to the kernel.
> > If you indicate OS capabilities, you can use whatever offset you  
> > want, of course.
> Excellent. We will modify the firmware accordingly and encode the  
> options.

Thanks. Would be nice if you could also do the corresponding driver patch.

> >> - what to do with rts procedure: we can implement this feature easily
> >> but I'm not sure about the value it can add to people (the majority  
> >> of
> >> users?) that use the bcm board in station mode. This is different for
> >> those who run a bcm card in AP mode, but we can clearly discourage
> >> them to run this firmware in AP mode if  not sure about rts usage by
> >> stations. However, we put this task in the todo list.
> >
> > RTS/CTS is not specific to AP mode. It's used on any station in the  
> > BSS.
> > See IEEE 802.11 specs.
> Yes, in fact we put this task in the todo list.

Thanks.

> >> - tx header layout: the opensource firmware is now using the old
> >> memory layout in the tx header (<351). Do you think switching to 410
> >> format is mandatory now or we can concentrate on the other tasks?
> >
> > Yes, the old format is deprecated and will be removed soon.
> Ok, first task in the todo list!

Well, doesn't need to the the first one. Just note that support for this is
scheduled to be removed in summer 2008. So if any problems show up (broadcom
releases yet another API, for example), I will immediately remove it.

> Ok, thanks for the hint. I will check,

There are a few things we're not yet sure about.
For example the operand for the GPR number got an additional bit.
But we're not sure if the real number of GPRs also was doubled in the hardware.
There are a few FIXMEs in the code for this...
I think this simply has to be tested by trial and error.

-- 
Greetings, Michael.