linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: Francesco Gringoli <francesco.gringoli@ing.unibs.it>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
	Johannes Berg <johannes@sipsolutions.net>,
	kyle@infradead.org, linux-wireless@vger.kernel.org,
	bcm43xx-dev@lists.berlios.de
Subject: Re: [b43] opensource firmware
Date: Fri, 16 Jan 2009 16:12:23 +0100	[thread overview]
Message-ID: <200901161612.24288.mb@bu3sch.de> (raw)
In-Reply-To: <65BB63A7-75ED-464D-AD81-E34F3AD560BE@ing.unibs.it>

On Friday 16 January 2009 00:01:41 Francesco Gringoli wrote:
> On Jan 15, 2009, at 4:59 PM, Larry Finger wrote:
> 
> > Michael Buesch wrote:
> >> Yes, please introduce a feature-bitfield at some location in SHM  
> >> that's unused
> >> by the proprietary firmware. This bitfields would contain a bit for  
> >> QoS and
> >> a bit for hwcrypto.
> >> Also change your firmware so the driver detects it as open-source  
> >> firmware.
> >> I think that's done by writing 0xFFFF to the date/time field in  
> >> SHM. I don't
> >> quite remember, but it's something like that.
> >> Note that this might mean that the firmware watchdog in the driver  
> >> will trigger,
> >> as that's enabled by the open-source-firmware-flag. We might want  
> >> to temporarly
> >> disable the watchdog in the driver for the time being.
> >
> > I like the idea of encoding the capabilities in the firmware as it
> > would be a self-documenting method as the firmware evolves.
> >
> > Is using the Broadcom names for the firmware the best course of
> > action? What if the opensource firmware files were named something
> > like "os-ucode5.fw", etc. and b43 were coded to check for those files
> > first? It would then fall back to the standard firmware if the
> > opensource version is not found.
> >
> > Larry
> It could be interesting to also not separate the initvalues in two  
> different files, everything could be coded in a single file. Never  
> understood why original init values are split in two files.

The normal initvalues have to be uploaded at init and the bandswitch init
values have to be uploaded on bandswitch. That's a different thing.
We currently implement bandswitch by re-initing, but that doesn't matter. We could
easily change that in future.
So don't put the initvals into one file.

> Michael: SHM(0x0014) (16bit) is not used by the open source firmware,  

Eh no. You need to find an offset that's not used by the PROPRIETARY firmware.

> A question: is the standard kernel aware that date set to FFFF  
> indicates an opensource firmware 

Yes.

-- 
Greetings, Michael.

  reply	other threads:[~2009-01-16 15:13 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-14 15:30 [b43] opensource firmware Lorenzo Nava
2009-01-14 15:33 ` John W. Linville
2009-01-14 15:57 ` Buran Ayuthia
2009-01-14 16:06   ` Lorenzo Nava
2009-01-14 17:43 ` Larry Finger
2009-01-14 17:48   ` Michael Buesch
2009-01-15  9:10   ` Lorenzo Nava
2009-01-15  9:45     ` gavron
2009-01-15 10:20       ` Lorenzo Nava
2009-01-14 20:45 ` Johannes Berg
2009-01-14 21:09   ` John W. Linville
2009-01-14 21:20     ` Johannes Berg
2009-01-14 21:32       ` Kyle McMartin
2009-01-15 15:37   ` Michael Buesch
2009-01-15 15:44     ` Michael Buesch
2009-01-15 15:59     ` Larry Finger
2009-01-15 16:09       ` Michael Buesch
2009-01-15 23:17         ` Kyle McMartin
2009-01-16 15:15           ` Michael Buesch
2009-01-15 23:01       ` Francesco Gringoli
2009-01-16 15:12         ` Michael Buesch [this message]
2009-01-21 17:29           ` Francesco Gringoli
2009-01-21 17:36             ` Michael Buesch
2009-01-25 18:37 ` Rafał Miłecki
  -- strict thread matches above, loose matches on Subject: below --
2009-01-09 10:29 Fwd: " Michael Buesch
2009-01-09 10:49 ` Michael Buesch
2009-01-09 10:58   ` Michael Buesch
2009-01-09 11:03     ` Francesco Gringoli
2009-01-09 11:00   ` Francesco Gringoli
2009-01-09 11:06     ` Michael Buesch
2009-01-09 11:11       ` Lorenzo Nava
2009-01-09 11:35       ` Lorenzo Nava
2009-01-10 17:37       ` Lorenzo Nava
2009-01-11  1:21         ` Buran Ayuthia
2009-01-12 15:39         ` John W. Linville
2009-01-12 15:48           ` Michael Buesch
2009-01-12 15:48           ` Francesco Gringoli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200901161612.24288.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=Larry.Finger@lwfinger.net \
    --cc=bcm43xx-dev@lists.berlios.de \
    --cc=francesco.gringoli@ing.unibs.it \
    --cc=johannes@sipsolutions.net \
    --cc=kyle@infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).