Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

[Luis R. Rodriguez]

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

Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

[Suraj Sumangala]

Hi Luis,

On 10/8/2010 10:32 PM, Luis Rodriguez wrote:
> Suraj,
>
> What is the difference between ath3k-2.fw and ath3k-1.fw ?

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 
differently?

>
> 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?

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 
change.

>
> 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

Regards
Suraj

Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

[Luis R. Rodriguez]

On Fri, Oct 08, 2010 at 10:27:36AM -0700, Suraj Sumangala wrote:
> Hi Luis,
> 
> On 10/8/2010 10:32 PM, Luis Rodriguez wrote:
> > Suraj,
> >
> > What is the difference between ath3k-2.fw and ath3k-1.fw ?
> 
> 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 
> differently?

Sure, agreed, but what about the sflash configuration fix?

> > 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?
> 
> 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 
> change.

> > I last tried to document a thread we had over this here:
> >
> > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
> >

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

 Luis

Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

[Sven-Haegar Koch]

On Fri, 8 Oct 2010, Luis R. Rodriguez wrote:

> > > I last tried to document a thread we had over this here:
> > >
> > > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
> > >
> 
> Thanks, I've updated that link above to document bug fixing does not require
> a filename change.

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.

Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

[Marcel Holtmann]

Hi Sven-Haeger,

> > > > I last tried to document a thread we had over this here:
> > > >
> > > > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
> > > >
> > 
> > Thanks, I've updated that link above to document bug fixing does not require
> > a filename change.
> 
> I would summarize it as:
> 
> If a new firmware version also works with an old driver, keep the filename.

correct.

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

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

Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

[Henry Ptasinski]

On Fri, Oct 08, 2010 at 11:15:08AM -0700, Luis R. Rodriguez wrote:
> On Fri, Oct 08, 2010 at 10:27:36AM -0700, Suraj Sumangala wrote:
> > 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 
> > change.
> 
> > > I last tried to document a thread we had over this here:
> > >
> > > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
> > >
> 
> Thanks, I've updated that link above to document bug fixing does not require
> a filename change.

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

Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

[Marcel Holtmann]

Hi Henry,

> > > 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 
> > > change.
> > 
> > > > I last tried to document a thread we had over this here:
> > > >
> > > > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
> > > >
> > 
> > Thanks, I've updated that link above to document bug fixing does not require
> > a filename change.
> 
> 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?

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

Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

[Luis R. Rodriguez]

On Wed, Oct 13, 2010 at 3:06 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Henry,
>
>> > > 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
>> > > change.
>> >
>> > > > I last tried to document a thread we had over this here:
>> > > >
>> > > > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
>> > > >
>> >
>> > Thanks, I've updated that link above to document bug fixing does not require
>> > a filename change.
>>
>> 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?
>
> 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.

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

RE: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

[Kevin Hayes]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2563 bytes --]

Hi Luis,


> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> owner@vger.kernel.org] On Behalf Of Luis R. Rodriguez
> Sent: Wednesday, October 13, 2010 10:43 AM
> To: Marcel Holtmann
> Cc: Henry Ptasinski; Suraj Sumangala; Luis Rodriguez; David Woodhouse;
> linux-bluetooth; linux-kernel@vger.kernel.org; linux-wireless
> Subject: Re: Firmware versioning best practices: ath3k-2.fw rename or
> replace ath3k-1.fw ?
> 
> On Wed, Oct 13, 2010 at 3:06 AM, Marcel Holtmann <marcel@holtmann.org>
> wrote:
> > Hi Henry,
> >
> >> > > 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
> >> > > change.
> >> >
> >> > > > I last tried to document a thread we had over this here:
> >> > > >
> >> > > >
> http://wireless.kernel.org/en/developers/Documentation/firmware-
> versioning
> >> > > >
> >> >
> >> > Thanks, I've updated that link above to document bug fixing does
> not require
> >> > a filename change.
> >>
> >> 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?
> >
> > 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.
> 
> 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

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++
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

[Luis R. Rodriguez]

On Wed, Oct 13, 2010 at 10:54 AM, Kevin Hayes <kevin@atheros.com> wrote:
> Hi Luis,
>
>
>> -----Original Message-----
>> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
>> owner@vger.kernel.org] On Behalf Of Luis R. Rodriguez
>> Sent: Wednesday, October 13, 2010 10:43 AM
>> To: Marcel Holtmann
>> Cc: Henry Ptasinski; Suraj Sumangala; Luis Rodriguez; David Woodhouse;
>> linux-bluetooth; linux-kernel@vger.kernel.org; linux-wireless
>> Subject: Re: Firmware versioning best practices: ath3k-2.fw rename or
>> replace ath3k-1.fw ?
>>
>> On Wed, Oct 13, 2010 at 3:06 AM, Marcel Holtmann <marcel@holtmann.org>
>> wrote:
>> > Hi Henry,
>> >
>> >> > > 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
>> >> > > change.
>> >> >
>> >> > > > I last tried to document a thread we had over this here:
>> >> > > >
>> >> > > >
>> http://wireless.kernel.org/en/developers/Documentation/firmware-
>> versioning
>> >> > > >
>> >> >
>> >> > Thanks, I've updated that link above to document bug fixing does
>> not require
>> >> > a filename change.
>> >>
>> >> 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?
>> >
>> > 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.
>>
>> 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
>
> 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.

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

  Luis

RE: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

[Kevin Hayes]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3882 bytes --]

Hi Luis,

> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> owner@vger.kernel.org] On Behalf Of Luis R. Rodriguez
> Sent: Wednesday, October 13, 2010 11:10 AM
> To: Kevin Hayes
> Cc: Luis Rodriguez; Marcel Holtmann; Henry Ptasinski; Suraj Sumangala;
> David Woodhouse; linux-bluetooth; linux-kernel@vger.kernel.org; linux-
> wireless
> Subject: Re: Firmware versioning best practices: ath3k-2.fw rename or
> replace ath3k-1.fw ?
> 
> On Wed, Oct 13, 2010 at 10:54 AM, Kevin Hayes <kevin@atheros.com>
> wrote:
> > Hi Luis,
> >
> >
> >> -----Original Message-----
> >> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> >> owner@vger.kernel.org] On Behalf Of Luis R. Rodriguez
> >> Sent: Wednesday, October 13, 2010 10:43 AM
> >> To: Marcel Holtmann
> >> Cc: Henry Ptasinski; Suraj Sumangala; Luis Rodriguez; David
> Woodhouse;
> >> linux-bluetooth; linux-kernel@vger.kernel.org; linux-wireless
> >> Subject: Re: Firmware versioning best practices: ath3k-2.fw rename
> or
> >> replace ath3k-1.fw ?
> >>
> >> On Wed, Oct 13, 2010 at 3:06 AM, Marcel Holtmann
> <marcel@holtmann.org>
> >> wrote:
> >> > Hi Henry,
> >> >
> >> >> > > 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
> >> >> > > change.
> >> >> >
> >> >> > > > I last tried to document a thread we had over this here:
> >> >> > > >
> >> >> > > >
> >> http://wireless.kernel.org/en/developers/Documentation/firmware-
> >> versioning
> >> >> > > >
> >> >> >
> >> >> > Thanks, I've updated that link above to document bug fixing
> does
> >> not require
> >> >> > a filename change.
> >> >>
> >> >> 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?
> >> >
> >> > 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.
> >>
> >> 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
> >
> > 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.
> 
> Does HCI support uploading firmware? Can't we resolve this blacklist
> crap issue if devices just used HCI to upload firmware?
> 
>   Luis
> --

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...]





ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

[Suraj Sumangala]

Hi Luis,

On 10/13/2010 11:39 PM, Luis R. Rodriguez wrote:
> Does HCI support uploading firmware? Can't we resolve this blacklist
> crap issue if devices just used HCI to upload firmware?

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 
firmware,  but we do download all configuration entries as VS HCI commands.
>
>    Luis

Regards
Suraj

Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

[Marcel Holtmann]

Hi Luis,

> 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?

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
what Bluetooth subsystem needs to do.

> 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...

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
have dangling firmware somewhere.

> 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?

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

Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?

[Senthil Balasubramanian]

On Sat, Oct 09, 2010 at 01:31:28PM +0530, Marcel Holtmann wrote:
> Hi Luis,
> 
> > 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?
> 
> that is what most companies do and that is what iwlwifi has done so far.
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
host driver depends on.

> 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
> what Bluetooth subsystem needs to do.
> 
> > 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...
> 
> 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
> have dangling firmware somewhere.
> 
> > 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?
> 
> 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
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html