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
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
SGkgTHVpcywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsaW51eC1i
bHVldG9vdGgtb3duZXJAdmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtYmx1ZXRvb3RoLQ0K
PiBvd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uIEJlaGFsZiBPZiBMdWlzIFIuIFJvZHJpZ3Vleg0K
PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTMsIDIwMTAgMTE6MTAgQU0NCj4gVG86IEtldmlu
IEhheWVzDQo+IENjOiBMdWlzIFJvZHJpZ3VlejsgTWFyY2VsIEhvbHRtYW5uOyBIZW5yeSBQdGFz
aW5za2k7IFN1cmFqIFN1bWFuZ2FsYTsNCj4gRGF2aWQgV29vZGhvdXNlOyBsaW51eC1ibHVldG9v
dGg7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LQ0KPiB3aXJlbGVzcw0KPiBT
dWJqZWN0OiBSZTogRmlybXdhcmUgdmVyc2lvbmluZyBiZXN0IHByYWN0aWNlczogYXRoM2stMi5m
dyByZW5hbWUgb3INCj4gcmVwbGFjZSBhdGgzay0xLmZ3ID8NCj4gDQo+IE9uIFdlZCwgT2N0IDEz
LCAyMDEwIGF0IDEwOjU0IEFNLCBLZXZpbiBIYXllcyA8a2V2aW5AYXRoZXJvcy5jb20+DQo+IHdy
b3RlOg0KPiA+IEhpIEx1aXMsDQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KPiA+PiBGcm9tOiBsaW51eC1ibHVldG9vdGgtb3duZXJAdmdlci5rZXJuZWwub3JnIFtt
YWlsdG86bGludXgtYmx1ZXRvb3RoLQ0KPiA+PiBvd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uIEJl
aGFsZiBPZiBMdWlzIFIuIFJvZHJpZ3Vleg0KPiA+PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIg
MTMsIDIwMTAgMTA6NDMgQU0NCj4gPj4gVG86IE1hcmNlbCBIb2x0bWFubg0KPiA+PiBDYzogSGVu
cnkgUHRhc2luc2tpOyBTdXJhaiBTdW1hbmdhbGE7IEx1aXMgUm9kcmlndWV6OyBEYXZpZA0KPiBX
b29kaG91c2U7DQo+ID4+IGxpbnV4LWJsdWV0b290aDsgbGludXgta2VybmVsQHZnZXIua2VybmVs
Lm9yZzsgbGludXgtd2lyZWxlc3MNCj4gPj4gU3ViamVjdDogUmU6IEZpcm13YXJlIHZlcnNpb25p
bmcgYmVzdCBwcmFjdGljZXM6IGF0aDNrLTIuZncgcmVuYW1lDQo+IG9yDQo+ID4+IHJlcGxhY2Ug
YXRoM2stMS5mdyA/DQo+ID4+DQo+ID4+IE9uIFdlZCwgT2N0IDEzLCAyMDEwIGF0IDM6MDYgQU0s
IE1hcmNlbCBIb2x0bWFubg0KPiA8bWFyY2VsQGhvbHRtYW5uLm9yZz4NCj4gPj4gd3JvdGU6DQo+
ID4+ID4gSGkgSGVucnksDQo+ID4+ID4NCj4gPj4gPj4gPiA+IE1hcmNlbCBoYWQgYW5zd2VyZWQg
bWUgYmVmb3JlLiBJdCBtYWtlcyBzZW5zZSB0byBoYXZlIHNhbWUNCj4gZmlsZQ0KPiA+PiBuYW1l
Lg0KPiA+PiA+PiA+ID4gT3RoZXIgd2F5cyB3ZSBlbmQgdXAgY2hhbmdpbmcgdGhlIGRyaXZlciB3
aGVuZXZlciB0aGVyZSBpcyBhDQo+ID4+IGZpcm13YXJlDQo+ID4+ID4+ID4gPiBjaGFuZ2UuDQo+
ID4+ID4+ID4NCj4gPj4gPj4gPiA+ID4gSSBsYXN0IHRyaWVkIHRvIGRvY3VtZW50IGEgdGhyZWFk
IHdlIGhhZCBvdmVyIHRoaXMgaGVyZToNCj4gPj4gPj4gPiA+ID4NCj4gPj4gPj4gPiA+ID4NCj4g
Pj4gaHR0cDovL3dpcmVsZXNzLmtlcm5lbC5vcmcvZW4vZGV2ZWxvcGVycy9Eb2N1bWVudGF0aW9u
L2Zpcm13YXJlLQ0KPiA+PiB2ZXJzaW9uaW5nDQo+ID4+ID4+ID4gPiA+DQo+ID4+ID4+ID4NCj4g
Pj4gPj4gPiBUaGFua3MsIEkndmUgdXBkYXRlZCB0aGF0IGxpbmsgYWJvdmUgdG8gZG9jdW1lbnQg
YnVnIGZpeGluZw0KPiBkb2VzDQo+ID4+IG5vdCByZXF1aXJlDQo+ID4+ID4+ID4gYSBmaWxlbmFt
ZSBjaGFuZ2UuDQo+ID4+ID4+DQo+ID4+ID4+IEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgd2h5
IHlvdSB3b3VsZCBub3Qgd2FudCB0byBjaGFuZ2UgdGhlDQo+IGNvZGUNCj4gPj4gcmV2aXNpb24N
Cj4gPj4gPj4gcGFydCBvZiB0aGUgZmlsZW5hbWUuDQo+ID4+ID4+DQo+ID4+ID4+IEkgdG90YWxs
eSBhZ3JlZSB0aGF0IHlvdSBkb24ndCB3YW50IHRvIGNoYW5nZSB0aGUgZHJpdmVyIGV2ZXJ5DQo+
IHRpbWUNCj4gPj4gdGhlDQo+ID4+ID4+IGZpcm13YXJlIGdldHMgYSBidWcgZml4LCBidXQgd2Fz
bid0IHRoYXQgdGhlIHdob2xlIHBvaW50IG9mDQo+ID4+IHNwbGl0dGluZyB0aGUgbmFtZQ0KPiA+
PiA+PiBpbnRvIEFQSSBhbmQgY29kZSByZXZpc2lvbnMgcG9ydGlvbnMsIGFuZCBzeW1saW5raW5n
IHRoZSBmaWxlIHRvDQo+IG9uZQ0KPiA+PiB0aGF0IGp1c3QNCj4gPj4gPj4gaGFzIHRoZSBBUEkg
dmVyc2lvbj8NCj4gPj4gPj4NCj4gPj4gPj4gV2hhdCdzIHRoZSBpc3N1ZSB3aXRoIHVzaW5nIHRo
ZSBwcm9jZXNzIGFzIG9yaWdpbmFsbHkgZG9jdW1lbnRlZD8NCj4gPj4gPg0KPiA+PiA+IGFzIEkg
c3RhdGVkIGJlZm9yZSwgZm9yIEJsdWV0b290aCB0aGlzIG1ha2VzIG5vIHNlbnNlLiBZb3UgZG9u
J3QNCj4gbmVlZA0KPiA+PiA+IEFQSSB2ZXJzaW9uIG51bWJlcnMgc2luY2UgdGhlIEFQSSBpcyBh
IFNUQU5EQVJELiBJdCBpcyBjYWxsZWQgSENJLg0KPiBTbw0KPiA+PiA+IHBsZWFzZSBkb24ndCB1
c2UgQVBJIHZlcnNpb24gbnVtYmVycyBpbiB0aGUgZmlybXdhcmUgZmlsZXMuDQo+ID4+ID4NCj4g
Pj4gPiBJIHdpbGwgcmVqZWN0IGZpcm13YXJlIGZpbGUgdmVyc2lvbnMgZm9yIHVwc3RyZWFtIGRy
aXZlcnMuDQo+ID4+DQo+ID4+IERvZXMgdGhlIEhDSSBzdGFuZGFyZCBldmVyIGdldCBpbXByb3Zl
ZCB1cG9uPyBJZiBzbywgaG93IGRvIGRldmljZXMNCj4gPj4gbmV2ZXIgZ2V0IGZpcm13YXJlIHVw
ZGF0ZXMgdGhhdCB3b3VsZCBhbGxvdyB0aGVtIHRvIHVzZSBzb21lIG5ld2VyDQo+IEhDSQ0KPiA+
PiBBUElzPw0KPiA+Pg0KPiA+PiBJJ3ZlIHVwZGF0ZWQgdGhlIGRvY3VtZW50YXRpb24gYWJvdmUg
Zm9yIDgwMi4xMSBhbmQgQmx1ZXRvb3RoIHdpdGgNCj4gdGhlDQo+ID4+IGFib3ZlLCBwbGVhc2Ug
ZmVlbCBmcmVlIHRvIGZ1cnRoZXIgZXh0ZW5kIGl0IGFzIHlvdSBzZWUgZml0Lg0KPiA+Pg0KPiA+
PiDCoCBMdWlzDQo+ID4NCj4gPiBIQ0kgaXMgYWx3YXlzIGJhY2t3YXJkIGNvbXBhdGlibGUuIMKg
TmV3ZXIgY29tbWFuZHMgYXJlIHByb3Blcmx5DQo+IGRpc2NvdmVyYWJsZSBieSBib3RoIHNpZGVz
IG9mIHRoZSBIQ0kgbGluay4NCj4gPiBBcyBsb25nIGFzIHRoZSBwcm9jZWR1cmUgdG8gZG93bmxv
YWQgZmlybXdhcmUgZG9lcyBub3QgZGVwZW5kIG9uIG5ldw0KPiBIQ0kgY29tbWFuZHMgKGl0IGRv
ZXMgbm90KSwgdGhlbiB0aGUgZmlybXdhcmUgaXRzZWxmIGNhbiB0ZWFjaCBhbiBvbGQNCj4gY29u
dHJvbGxlciB0byBsZWFybiBuZXcgdHJpY2tzLg0KPiANCj4gRG9lcyBIQ0kgc3VwcG9ydCB1cGxv
YWRpbmcgZmlybXdhcmU/IENhbid0IHdlIHJlc29sdmUgdGhpcyBibGFja2xpc3QNCj4gY3JhcCBp
c3N1ZSBpZiBkZXZpY2VzIGp1c3QgdXNlZCBIQ0kgdG8gdXBsb2FkIGZpcm13YXJlPw0KPiANCj4g
ICBMdWlzDQo+IC0tDQoNCk5vdCByZWFsbHkgYmVjYXVzZSB0aGVyZSBpcyBub3QgZW5vdWdoIHNw
YWNlIGluIHRoZSBzZmxhc2ggdG8gZG8gbXVjaCBvZiBhbnl0aGluZyBleGNlcHQgcmVwb3J0IHRo
ZSBQSUQuDQpJdCBtdXN0IGJlIHNvbWUgZXh0ZXJuYWwgY29kZSB0aGF0IHBpY2tzIHRoZSBmaXJt
d2FyZSB0byBsb2FkIGFuZCBpbmplY3QgaXQgaW50byB0aGUgY29udHJvbGxlci4NClRoYXQgZXh0
ZXJuYWwgY29kZSBpcyB0aGUgREZVIGJpdC4gIFdlIG11c3QgYmxhY2tsaXN0IHRoZSBkZXZpY2Ug
c28gdGhhdCBidHVzYiBkb2VzIG5vdCBjbGFpbSBpdCwgc28gd2UgY2FuIHVzZSB0aGUgREZVLg0K
DQogICAgSysrDQoNCltQYXJkb24gdGhlIGdhcmJhZ2UgdGhhdCBvdXIgbWFpbCBzZXJ2ZXIgYWRk
cy4uLl0NCg0KDQoNCg0KDQo=
On Wed, Oct 13, 2010 at 10:54 AM, Kevin Hayes <[email protected]> wrote:
> Hi Luis,
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:linux-bluetooth-
>> [email protected]] 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; [email protected]; 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 <[email protected]>
>> 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.
>>
>> =C2=A0 Luis
>
> HCI is always backward compatible. =C2=A0Newer commands are properly disc=
overable 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 controlle=
r 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
SGkgTHVpcywNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGxpbnV4
LWJsdWV0b290aC1vd25lckB2Z2VyLmtlcm5lbC5vcmcgW21haWx0bzpsaW51eC1ibHVldG9vdGgt
DQo+IG93bmVyQHZnZXIua2VybmVsLm9yZ10gT24gQmVoYWxmIE9mIEx1aXMgUi4gUm9kcmlndWV6
DQo+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxMywgMjAxMCAxMDo0MyBBTQ0KPiBUbzogTWFy
Y2VsIEhvbHRtYW5uDQo+IENjOiBIZW5yeSBQdGFzaW5za2k7IFN1cmFqIFN1bWFuZ2FsYTsgTHVp
cyBSb2RyaWd1ZXo7IERhdmlkIFdvb2Rob3VzZTsNCj4gbGludXgtYmx1ZXRvb3RoOyBsaW51eC1r
ZXJuZWxAdmdlci5rZXJuZWwub3JnOyBsaW51eC13aXJlbGVzcw0KPiBTdWJqZWN0OiBSZTogRmly
bXdhcmUgdmVyc2lvbmluZyBiZXN0IHByYWN0aWNlczogYXRoM2stMi5mdyByZW5hbWUgb3INCj4g
cmVwbGFjZSBhdGgzay0xLmZ3ID8NCj4gDQo+IE9uIFdlZCwgT2N0IDEzLCAyMDEwIGF0IDM6MDYg
QU0sIE1hcmNlbCBIb2x0bWFubiA8bWFyY2VsQGhvbHRtYW5uLm9yZz4NCj4gd3JvdGU6DQo+ID4g
SGkgSGVucnksDQo+ID4NCj4gPj4gPiA+IE1hcmNlbCBoYWQgYW5zd2VyZWQgbWUgYmVmb3JlLiBJ
dCBtYWtlcyBzZW5zZSB0byBoYXZlIHNhbWUgZmlsZQ0KPiBuYW1lLg0KPiA+PiA+ID4gT3RoZXIg
d2F5cyB3ZSBlbmQgdXAgY2hhbmdpbmcgdGhlIGRyaXZlciB3aGVuZXZlciB0aGVyZSBpcyBhDQo+
IGZpcm13YXJlDQo+ID4+ID4gPiBjaGFuZ2UuDQo+ID4+ID4NCj4gPj4gPiA+ID4gSSBsYXN0IHRy
aWVkIHRvIGRvY3VtZW50IGEgdGhyZWFkIHdlIGhhZCBvdmVyIHRoaXMgaGVyZToNCj4gPj4gPiA+
ID4NCj4gPj4gPiA+ID4NCj4gaHR0cDovL3dpcmVsZXNzLmtlcm5lbC5vcmcvZW4vZGV2ZWxvcGVy
cy9Eb2N1bWVudGF0aW9uL2Zpcm13YXJlLQ0KPiB2ZXJzaW9uaW5nDQo+ID4+ID4gPiA+DQo+ID4+
ID4NCj4gPj4gPiBUaGFua3MsIEkndmUgdXBkYXRlZCB0aGF0IGxpbmsgYWJvdmUgdG8gZG9jdW1l
bnQgYnVnIGZpeGluZyBkb2VzDQo+IG5vdCByZXF1aXJlDQo+ID4+ID4gYSBmaWxlbmFtZSBjaGFu
Z2UuDQo+ID4+DQo+ID4+IEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgd2h5IHlvdSB3b3VsZCBu
b3Qgd2FudCB0byBjaGFuZ2UgdGhlIGNvZGUNCj4gcmV2aXNpb24NCj4gPj4gcGFydCBvZiB0aGUg
ZmlsZW5hbWUuDQo+ID4+DQo+ID4+IEkgdG90YWxseSBhZ3JlZSB0aGF0IHlvdSBkb24ndCB3YW50
IHRvIGNoYW5nZSB0aGUgZHJpdmVyIGV2ZXJ5IHRpbWUNCj4gdGhlDQo+ID4+IGZpcm13YXJlIGdl
dHMgYSBidWcgZml4LCBidXQgd2Fzbid0IHRoYXQgdGhlIHdob2xlIHBvaW50IG9mDQo+IHNwbGl0
dGluZyB0aGUgbmFtZQ0KPiA+PiBpbnRvIEFQSSBhbmQgY29kZSByZXZpc2lvbnMgcG9ydGlvbnMs
IGFuZCBzeW1saW5raW5nIHRoZSBmaWxlIHRvIG9uZQ0KPiB0aGF0IGp1c3QNCj4gPj4gaGFzIHRo
ZSBBUEkgdmVyc2lvbj8NCj4gPj4NCj4gPj4gV2hhdCdzIHRoZSBpc3N1ZSB3aXRoIHVzaW5nIHRo
ZSBwcm9jZXNzIGFzIG9yaWdpbmFsbHkgZG9jdW1lbnRlZD8NCj4gPg0KPiA+IGFzIEkgc3RhdGVk
IGJlZm9yZSwgZm9yIEJsdWV0b290aCB0aGlzIG1ha2VzIG5vIHNlbnNlLiBZb3UgZG9uJ3QgbmVl
ZA0KPiA+IEFQSSB2ZXJzaW9uIG51bWJlcnMgc2luY2UgdGhlIEFQSSBpcyBhIFNUQU5EQVJELiBJ
dCBpcyBjYWxsZWQgSENJLiBTbw0KPiA+IHBsZWFzZSBkb24ndCB1c2UgQVBJIHZlcnNpb24gbnVt
YmVycyBpbiB0aGUgZmlybXdhcmUgZmlsZXMuDQo+ID4NCj4gPiBJIHdpbGwgcmVqZWN0IGZpcm13
YXJlIGZpbGUgdmVyc2lvbnMgZm9yIHVwc3RyZWFtIGRyaXZlcnMuDQo+IA0KPiBEb2VzIHRoZSBI
Q0kgc3RhbmRhcmQgZXZlciBnZXQgaW1wcm92ZWQgdXBvbj8gSWYgc28sIGhvdyBkbyBkZXZpY2Vz
DQo+IG5ldmVyIGdldCBmaXJtd2FyZSB1cGRhdGVzIHRoYXQgd291bGQgYWxsb3cgdGhlbSB0byB1
c2Ugc29tZSBuZXdlciBIQ0kNCj4gQVBJcz8NCj4gDQo+IEkndmUgdXBkYXRlZCB0aGUgZG9jdW1l
bnRhdGlvbiBhYm92ZSBmb3IgODAyLjExIGFuZCBCbHVldG9vdGggd2l0aCB0aGUNCj4gYWJvdmUs
IHBsZWFzZSBmZWVsIGZyZWUgdG8gZnVydGhlciBleHRlbmQgaXQgYXMgeW91IHNlZSBmaXQuDQo+
IA0KPiAgIEx1aXMNCg0KSENJIGlzIGFsd2F5cyBiYWNrd2FyZCBjb21wYXRpYmxlLiAgTmV3ZXIg
Y29tbWFuZHMgYXJlIHByb3Blcmx5IGRpc2NvdmVyYWJsZSBieSBib3RoIHNpZGVzIG9mIHRoZSBI
Q0kgbGluay4NCkFzIGxvbmcgYXMgdGhlIHByb2NlZHVyZSB0byBkb3dubG9hZCBmaXJtd2FyZSBk
b2VzIG5vdCBkZXBlbmQgb24gbmV3IEhDSSBjb21tYW5kcyAoaXQgZG9lcyBub3QpLCB0aGVuIHRo
ZSBmaXJtd2FyZSBpdHNlbGYgY2FuIHRlYWNoIGFuIG9sZCBjb250cm9sbGVyIHRvIGxlYXJuIG5l
dyB0cmlja3MuDQoNCglLKysNCg==
On Wed, Oct 13, 2010 at 3:06 AM, Marcel Holtmann <[email protected]> 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
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
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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
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.
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
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