From: Michael Buesch <mb@bu3sch.de>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: bcm43xx devel <Bcm43xx-dev@lists.berlios.de>,
wireless <linux-wireless@vger.kernel.org>
Subject: Re: RFC: A workaround for BCM43XX devices with no on-board SPROM
Date: Fri, 19 Mar 2010 08:36:58 +0100 [thread overview]
Message-ID: <201003190836.58688.mb@bu3sch.de> (raw)
In-Reply-To: <4BA29D49.80707@lwfinger.net>
On Thursday 18 March 2010 22:38:17 Larry Finger wrote:
> On 03/18/2010 02:31 PM, Michael Buesch wrote:
> > On Thursday 18 March 2010 18:46:35 Larry Finger wrote:
> >> (1) Modify b43-fwcutter to take data from an existing SPROM,
> >
> > Why not extend the ssb-sprom tool? I don't think this has anything to do with
> > firmware, except that we (ab)use the firmware loading mechanism of the kernel
> > for loading the blob into the kernel.
>
> It has nothing to do with firmware, but the existing fwcutter has all the parts
> to generate files in the firmware directory,
Everything needed to "generate a file in the firmware directory" are the open()
write() and close() syscalls.
> >
> >> I have chosen to implement this in
> >> fwcutter rather than ssb_sprom because the ordinary user will not have access to
> >> ssb_sprom;
> >
> > Huh? ssb-sprom is GPL software. I have no problem relicensing it under BSD or
> > even something more liberal. I don't see a problem for "ordinary users" here.
>
> It has nothing to do with the license. My distro, openSUSE, packages fwcutter
> along with a script that uses wget to download the Broadcom drivers and extract
> firmware for both b43 and b43legacy. The average user only has to execute that
> script. Of course, the package could include both fwcutter and ssb_sprom
> programs, but that would make a bigger change to the openSUSE package than just
> a patch to fwcutter. I suspect that other distros use similar packages.
>
> > Well, but that version won't do anything on the SPROM, too.
>
> Yes, but if fwcutter were modified, it could write the virtual SPROM file.
I think it really is abuse of fwcutter.
What if you don't want any proprietary firmware at all, but still want an SPROM image?
What about distros that do _not_ automatically use fwcutter to put proprietary fw in place
for legal reasons? (Which most likely is the majority of distributions).
Why create yet another dependency on fwcutter. I thought the long term plan was to get rid
of proprietary firmware and fwcutter?
Is it really such a big deal for a distribution to include yet another tiny opensource
package? If that really is a problem for a distribution, they should just completely
stop doing their distro.
--
Greetings, Michael.
next prev parent reply other threads:[~2010-03-19 7:37 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-18 17:46 RFC: A workaround for BCM43XX devices with no on-board SPROM Larry Finger
2010-03-18 19:31 ` Michael Buesch
2010-03-18 20:20 ` John W. Linville
2010-03-18 20:31 ` Johannes Berg
2010-03-18 21:38 ` Larry Finger
2010-03-19 7:36 ` Michael Buesch [this message]
2010-03-18 20:51 ` Nicolas de Pesloüan
2010-03-18 20:53 ` Johannes Berg
2010-03-18 21:10 ` Larry Finger
2010-03-18 21:20 ` Johannes Berg
2010-03-18 21:47 ` Larry Finger
2010-03-19 18:40 ` Kalle Valo
2010-03-19 19:08 ` [PATCH] ssb: do not read SPROM if it does not exist John W. Linville
2010-03-19 19:41 ` Michael Buesch
2010-03-19 19:46 ` Michael Buesch
2010-03-19 20:21 ` John W. Linville
2010-03-19 20:30 ` Michael Buesch
2010-03-19 20:31 ` John W. Linville
2010-03-19 20:33 ` [PATCH v2] " John W. Linville
2010-03-19 20:41 ` [PATCH v3] " John W. Linville
2010-03-19 21:12 ` Michael Buesch
2010-03-19 22:10 ` John W. Linville
2010-03-19 22:10 ` [PATCH v4] " John W. Linville
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=201003190836.58688.mb@bu3sch.de \
--to=mb@bu3sch.de \
--cc=Bcm43xx-dev@lists.berlios.de \
--cc=Larry.Finger@lwfinger.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.