Suraj,

What is the difference between ath3k-2.fw and ath3k-1.fw ?

Won't the API change now that you are addressing the sflash
configuration fix? Would it not help to identify the two
different firmwares then?

David, Marcel, what are your preferences for a firmware upgrade
where the firmware does not change API (lets just pretend it does
not for a moment) ? Do we keep the same filename?

In this particular case I would assume our new sflash configuration
fix that might be being worked on might change the re-enumerated
USB device IDs so it seems to me a good idea to use a new filename.
I should note ath3k-2.fw already made it to linux-firmware.git...

I last tried to document a thread we had over this here:

http://wireless.kernel.org/en/developers/Documentation/firmware-versioning

Does this sound sane? If so then the sflash configuration fix
would seem to me like it would require a new filename. Now, while
we're at it, how about bug fixes?

Suraj -- keep these discussions public please....

  Luis
--

[ message continues ]

Hi Luis,


This is the same question for which I have been trying to get an answer.
The only information that I got was it fixes some critical bug and 
support shared antenna.

If ath3k-2.fw is an upgrade of ath3k-1.fw why do we need to name it 

Marcel had answered me before. It makes sense to have same file name.
Other ways we end up changing the driver whenever there is a firmware 

Regards
Suraj

--

[ message continues ]

Thanks, I've updated that link above to document bug fixing does not require
a filename change.

 Luis
--

[ message continues ]

I would summarize it as:

If a new firmware version also works with an old driver, keep the filename.

If a new firmware version also requires a new driver, change the name.

If a new driver requires a new firmware, change the name.

c'ya
sven-haegar

-- 
Three may keep a secret, if two of them are dead.
- Ben F.
--

[ message continues ]

These two depend. The exposed API stays the same. The firmware file
itself is the same. Just the loading procedure is different. So no need
to change the firmware name.

Let me repeat this. If the API of the firmware exposed after loading it,
breaks or is incompatible, then you need a new name.

If you have generic commands to detect features in the firmware, then
you should never be needed to change your firmware name. So you could
extend the API as much as you like with keeping the same name.

The different firmware names are for the driver to be able to detect the
API of the firmware. And only if that is only possible via the filename
you should use different filenames. Otherwise don't bother and use the
generic feature detection of the firmware itself.

And for Bluetooth in specific that is HCI. So any company needed
different firmware filenames for Bluetooth have done something really
really wrong in their development cycles.

Regards

Marcel


--

[ message continues ]

I don't really understand why you would not want to change the code revision
part of the filename.  

I totally agree that you don't want to change the driver every time the
firmware gets a bug fix, but wasn't that the whole point of splitting the name
into API and code revisions portions, and symlinking the file to one that just
has the API version?

What's the issue with using the process as originally documented?

- Henry


--

[ message continues ]

as I stated before, for Bluetooth this makes no sense. You don't need
API version numbers since the API is a STANDARD. It is called HCI. So
please don't use API version numbers in the firmware files.

I will reject firmware file versions for upstream drivers.

Regards

Marcel


--

[ message continues ]

Does the HCI standard ever get improved upon? If so, how do devices
never get firmware updates that would allow them to use some newer HCI
APIs?

I've updated the documentation above for 802.11 and Bluetooth with the
above, please feel free to further extend it as you see fit.

  Luis
--

[ message continues ]

HCI is always backward compatible.  Newer commands are properly discoverable by both sides of the HCI link.
As long as the procedure to download firmware does not depend on new HCI commands (it does not), then the firmware itself can teach an old controller to learn new tricks.

	K++
[ message continues ]

Does HCI support uploading firmware? Can't we resolve this blacklist
crap issue if devices just used HCI to upload firmware?

  Luis
--

[ message continues ]

Not really because there is not enough space in the sflash to do much of anything except report the PID.
It must be some external code that picks the firmware to load and inject it into the controller.
That external code is the DFU bit.  We must blacklist the device so that btusb does not claim it, so we can use the DFU.

    K++

[Pardon the garbage that our mail server adds...]





[ message continues ]

Hi Luis,


HCI does not support uploading firmware. But HCI does provide options 
for vendor specific commands that can be used for uploading firmware as 
long as your device has enough intelligence to understand the command 
when it comes.

This is what we do for AR300x serial devices. We do not download 

Regards
Suraj
--

[ message continues ]

that is what most companies do and that is what iwlwifi has done so far.
Only if the API breaks a different suffix is used.

With Bluetooth this should be never needed at all. The reason is that
you need to expose Bluetooth HCI. And that has generic version, support
commands and supported features commands.

We are not even using the version information for anything useful these
days since the firmware has to identify its features and its supported
commands with standard HCI commands. So it is pretty simple to detect

No it does not. The changed PID is not a breakage. It will just keep
working. So please fix this in linux-firmware.git right away and remove
the new firmware file.

And here is something that is wrong with your process as well. Don't
submit firmware files upstream before the upstream maintainers accepted
your driver or patch.

I know it is nice to have the firmware available quickly, but if your
driver gets rejected for the reason we have stated in this thread, you

If your firmware files are identical and the exposed API is identical
(in this case Bluetooth HCI), then you do NO need a new filename.

Regards

Marcel


--

[ message continues ]

Luis

this is what we have been doing for our ath9k_htc driver. We kept the same
fie name for firmware updates as we haven't changed any APIs/interfaces that
--

[ message continues ]