Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162339Ab3DESIX (ORCPT ); Fri, 5 Apr 2013 14:08:23 -0400 Received: from mail-ee0-f49.google.com ([74.125.83.49]:50901 "EHLO mail-ee0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1162274Ab3DESIV (ORCPT ); Fri, 5 Apr 2013 14:08:21 -0400 From: Christian Lamparter To: Eugene Krasnikov Subject: Re: Version number policy! Date: Fri, 5 Apr 2013 20:08:14 +0200 User-Agent: KMail/1.13.7 (Linux/3.9.0-rc5-wl+; KDE/4.8.4; x86_64; ; ) Cc: "Luis R. Rodriguez" , "linux-bluetooth" , Adrian Chadd , "linux-wireless" , "ath9k_htc_fw" , "linux-kernel@vger.kernel.org" References: <201304051903.11215.chunkeey@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304052008.15412.chunkeey@googlemail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2183 Lines: 57 On Friday 05 April 2013 19:23:54 Eugene Krasnikov wrote: > When it comes to feature bitmap do you have an example of such a > bitmap from carl9170? That's a weird way of asking. No, I don't have an example?! But carl9170fw_feature_list is used in "production". Anyway, there is one defined in: It's packed into the OTUS firmware descriptor: And the descriptor is filled in: [Basically, a bit for every feature in kconfig.] Of course, the nice thing is, if you have something like kconfig (carl9170fw.git uses a pretty much the vanilla kernel kconfig. Everything apart from the cmake scripts for gperf (which is in extra/) is packed into the conf/ directory. And it has the necessary cmake files. So it should integrate well into the "new" ath9k_htc cmake build system Felix made. > Why not to rely always on major version? Ok, let's do the same with major version... if ((fw_major == 1 && fw_minor > 30) || (fw_major == 2 && fw_minor > 7) || (fw_major == 3 && fw_minor > 3) || (fw_major > 4)) feature_supported = true; Nope, I think it looks just as bad. [Please, explain what you meant to say... Because the new versioning draft stats that very major release is incompatible with the old one and clearly, having to support a ton of different firmware trees is no joy.... and not necessary] BTW: Instead of a GET_BUILD command, why not make a add a firmware header or pack the information into the tail... This way, it can be read and parsed by tools, without having to upload it to the device first. carl9170fw already such a tool, it's called: fwinfo and it is located in: Regards, Christian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/