Re: [RESEND] Re: updating carl9170-1.fw in linux-firmware.git

[Ben Hutchings <ben@decadent.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 4090 bytes --]

On Wed, 2016-04-20 at 23:11 +0200, Christian Lamparter wrote:
> On Wednesday, April 20, 2016 10:59:44 AM Kalle Valo wrote:
> > Christian Lamparter <chunkeey@googlemail.com> writes:
> > 
> > > On Monday, April 18, 2016 07:42:05 PM Kalle Valo wrote:
> > > > Christian Lamparter <chunkeey@googlemail.com> writes:
> > > > 
> > > > > On Monday, April 18, 2016 06:45:09 PM Kalle Valo wrote:
> > > > > 
> > > > > > Why even mention anything about a "special firmware" as the firmware is
> > > > > > already available from linux-firmware.git? 
> > > > > 
> > > > > Yes and no. 1.9.6 is in linux-firmware.git. I've tried to add 1.9.9 too
> > > > > but that failed.
> > > > > 
> > > > 
> > > > Rick's comment makes sense to me, better just to provide the latest
> > > > version. No need to unnecessary confuse the users. And if someone really
> > > > wants to use an older version that she can retrieve it from the git
> > > > history.
> > > 
> > > Part of the fun here is that firmware is GPLv2. The linux-firmware.git has
> > > to point to or add the firmware source to their tree. They have added every
> > > single source file to it.... instead of "packaging" it in a tar.bz2/gz/xz
> > > like you normally do for release sources.
> > > 
> > > If you want to read more about it:
> > > <http://www.spinics.net/lists/linux-wireless/msg101868.html>
> > 
> > Yeah, that's more work. I get that. But I'm still not understanding
> > what's the actual problem which prevents us from updating carl9170
> > firmware in linux-firmware.
> I'm not sure, but why not ask? I've added the cc'ed Linux Firmware
> Maintainers. So for those people reading the fw list:
> 
> What would it take to update the carl9170-1.fw firmware file in your
> repository to the latest version?
> 
> Who has to sent the firmware update. Does it have to be the person who
> sent the first request? (Xose)? The maintainer of the firmware (me)?
> someone from Qualcomm Atheros? Or someone else (specific)? (the 
> firmware is licensed as GPLv2 - in theory anyone should be able to
> do that)

Given the licence, I don't particularly care.

> How should the firmware source update be handled? Currently the latest
> .tar.xz of the firmware has ~130kb. The formated patches from 1.9.6 to
> latest are about ~100kb (182 individual patches).

Either patches that 'git am' can handle, or a git branch.

> How does linux-firmware handle new binary firmware images and new 
> sources? What if carl9170fw-2.bin is added. Do we need another
> source directory for this in the current tree then? Because 
> carl9170fw-1.bin will still be needed for backwards compatibility
> so we basically need to duplicate parts of the source?

We still need to include the old binary for compatibility, and the old
source for GPL compliance.  (If there was a source version that could
build firmware for both ABI versions, then we could update both
binaries and have one set of source files.  But it doesn't sound like
that's the case.)

> Also, how's the situation with ath9k_htc? The 1.4.0 image contains
> some GPLv2 code as well?

I didn't realise that.

> So, why is there no source in the tree, but just the link to it?

An oversight which we need to fix.

> Because, I would like to do basically the same
> for carl9170fw and just add a link to the carl9170fw repository and
> save everyone this source update "song and dance".

Merely linking to upstream source doesn't satisfy GPLv2 source
requirements, at least not in case of commercial distribution.  Linux
distributors should be able to use a snapshot of linux-firmware as the
upstream source for a package, without worrying about whether there are
extra sources they need to include.

(I'm aware that there are several files that don't actually have clear
licences for.  But those are at least called out in WHENCE, and were
previously distributed as part of the kernel sources for years.)

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at
once.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]