On Wed, 2016-04-20 at 23:11 +0200, Christian Lamparter wrote:

On Wednesday, April 20, 2016 10:59:44 AM Kalle Valo wrote:

quoted

Christian Lamparter [off-list ref] writes:

quoted

On Monday, April 18, 2016 07:42:05 PM Kalle Valo wrote:

quoted

Christian Lamparter [off-list ref] writes:

quoted

On Monday, April 18, 2016 06:45:09 PM Kalle Valo wrote:

quoted

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.