* Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? @ 2010-10-08 17:02 Luis R. Rodriguez 2010-10-08 17:27 ` Suraj Sumangala 2010-10-09 8:01 ` Marcel Holtmann 0 siblings, 2 replies; 14+ messages in thread From: Luis R. Rodriguez @ 2010-10-08 17:02 UTC (permalink / raw) To: Suraj Sumangala, David Woodhouse, Marcel Holtmann Cc: linux-bluetooth, linux-kernel, linux-wireless 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? 2010-10-08 17:02 Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? Luis R. Rodriguez @ 2010-10-08 17:27 ` Suraj Sumangala 2010-10-08 18:15 ` Luis R. Rodriguez 2010-10-09 8:01 ` Marcel Holtmann 1 sibling, 1 reply; 14+ messages in thread From: Suraj Sumangala @ 2010-10-08 17:27 UTC (permalink / raw) To: Luis Rodriguez Cc: Suraj Sumangala, David Woodhouse, Marcel Holtmann, linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? 2010-10-08 17:27 ` Suraj Sumangala @ 2010-10-08 18:15 ` Luis R. Rodriguez 2010-10-08 22:47 ` Sven-Haegar Koch 2010-10-12 21:17 ` Henry Ptasinski 0 siblings, 2 replies; 14+ messages in thread From: Luis R. Rodriguez @ 2010-10-08 18:15 UTC (permalink / raw) To: Suraj Sumangala Cc: Luis Rodriguez, David Woodhouse, Marcel Holtmann, linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? 2010-10-08 18:15 ` Luis R. Rodriguez @ 2010-10-08 22:47 ` Sven-Haegar Koch 2010-10-09 8:06 ` Marcel Holtmann 2010-10-12 21:17 ` Henry Ptasinski 1 sibling, 1 reply; 14+ messages in thread From: Sven-Haegar Koch @ 2010-10-08 22:47 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Suraj Sumangala, Luis Rodriguez, David Woodhouse, Marcel Holtmann, linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? 2010-10-08 22:47 ` Sven-Haegar Koch @ 2010-10-09 8:06 ` Marcel Holtmann 0 siblings, 0 replies; 14+ messages in thread From: Marcel Holtmann @ 2010-10-09 8:06 UTC (permalink / raw) To: Sven-Haegar Koch Cc: Luis R. Rodriguez, Suraj Sumangala, Luis Rodriguez, David Woodhouse, linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? 2010-10-08 18:15 ` Luis R. Rodriguez 2010-10-08 22:47 ` Sven-Haegar Koch @ 2010-10-12 21:17 ` Henry Ptasinski 2010-10-13 10:06 ` Marcel Holtmann 1 sibling, 1 reply; 14+ messages in thread From: Henry Ptasinski @ 2010-10-12 21:17 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Suraj Sumangala, Luis Rodriguez, David Woodhouse, Marcel Holtmann, linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless, 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? 2010-10-12 21:17 ` Henry Ptasinski @ 2010-10-13 10:06 ` Marcel Holtmann 2010-10-13 17:42 ` Luis R. Rodriguez 0 siblings, 1 reply; 14+ messages in thread From: Marcel Holtmann @ 2010-10-13 10:06 UTC (permalink / raw) To: Henry Ptasinski Cc: Luis R. Rodriguez, Suraj Sumangala, Luis Rodriguez, David Woodhouse, linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? 2010-10-13 10:06 ` Marcel Holtmann @ 2010-10-13 17:42 ` Luis R. Rodriguez 2010-10-13 17:54 ` Kevin Hayes 0 siblings, 1 reply; 14+ messages in thread From: Luis R. Rodriguez @ 2010-10-13 17:42 UTC (permalink / raw) To: Marcel Holtmann Cc: Henry Ptasinski, Suraj Sumangala, Luis Rodriguez, David Woodhouse, linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? 2010-10-13 17:42 ` Luis R. Rodriguez @ 2010-10-13 17:54 ` Kevin Hayes 2010-10-13 18:09 ` Luis R. Rodriguez 0 siblings, 1 reply; 14+ messages in thread From: Kevin Hayes @ 2010-10-13 17:54 UTC (permalink / raw) To: Luis Rodriguez, Marcel Holtmann Cc: Henry Ptasinski, Suraj Sumangala, Luis Rodriguez, David Woodhouse, linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless 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== ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? 2010-10-13 17:54 ` Kevin Hayes @ 2010-10-13 18:09 ` Luis R. Rodriguez 2010-10-13 18:41 ` Kevin Hayes 2010-10-14 4:23 ` Suraj Sumangala 0 siblings, 2 replies; 14+ messages in thread From: Luis R. Rodriguez @ 2010-10-13 18:09 UTC (permalink / raw) To: Kevin Hayes Cc: Luis Rodriguez, Marcel Holtmann, Henry Ptasinski, Suraj Sumangala, David Woodhouse, linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? 2010-10-13 18:09 ` Luis R. Rodriguez @ 2010-10-13 18:41 ` Kevin Hayes 2010-10-14 4:23 ` Suraj Sumangala 1 sibling, 0 replies; 14+ messages in thread From: Kevin Hayes @ 2010-10-13 18:41 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Luis Rodriguez, Marcel Holtmann, Henry Ptasinski, Suraj Sumangala, David Woodhouse, linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless 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= ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? 2010-10-13 18:09 ` Luis R. Rodriguez 2010-10-13 18:41 ` Kevin Hayes @ 2010-10-14 4:23 ` Suraj Sumangala 1 sibling, 0 replies; 14+ messages in thread From: Suraj Sumangala @ 2010-10-14 4:23 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Kevin Hayes, Luis Rodriguez, Marcel Holtmann, Henry Ptasinski, Suraj Sumangala, David Woodhouse, linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? 2010-10-08 17:02 Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? Luis R. Rodriguez 2010-10-08 17:27 ` Suraj Sumangala @ 2010-10-09 8:01 ` Marcel Holtmann 2010-10-11 7:14 ` Senthil Balasubramanian 1 sibling, 1 reply; 14+ messages in thread From: Marcel Holtmann @ 2010-10-09 8:01 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Suraj Sumangala, David Woodhouse, linux-bluetooth, linux-kernel, linux-wireless 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? 2010-10-09 8:01 ` Marcel Holtmann @ 2010-10-11 7:14 ` Senthil Balasubramanian 0 siblings, 0 replies; 14+ messages in thread From: Senthil Balasubramanian @ 2010-10-11 7:14 UTC (permalink / raw) To: Luis Rodriguez Cc: Suraj Sumangala, Marcel Holtmann, David Woodhouse, linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2010-10-14 4:23 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-10-08 17:02 Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ? Luis R. Rodriguez 2010-10-08 17:27 ` Suraj Sumangala 2010-10-08 18:15 ` Luis R. Rodriguez 2010-10-08 22:47 ` Sven-Haegar Koch 2010-10-09 8:06 ` Marcel Holtmann 2010-10-12 21:17 ` Henry Ptasinski 2010-10-13 10:06 ` Marcel Holtmann 2010-10-13 17:42 ` Luis R. Rodriguez 2010-10-13 17:54 ` Kevin Hayes 2010-10-13 18:09 ` Luis R. Rodriguez 2010-10-13 18:41 ` Kevin Hayes 2010-10-14 4:23 ` Suraj Sumangala 2010-10-09 8:01 ` Marcel Holtmann 2010-10-11 7:14 ` Senthil Balasubramanian
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).