From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE8E3C433FE for ; Thu, 28 Oct 2021 14:00:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C2E1861056 for ; Thu, 28 Oct 2021 14:00:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231222AbhJ1ODK convert rfc822-to-8bit (ORCPT ); Thu, 28 Oct 2021 10:03:10 -0400 Received: from coyote.holtmann.net ([212.227.132.17]:51568 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231218AbhJ1OCu (ORCPT ); Thu, 28 Oct 2021 10:02:50 -0400 Received: from smtpclient.apple (p4ff9fd51.dip0.t-ipconnect.de [79.249.253.81]) by mail.holtmann.org (Postfix) with ESMTPSA id 60E6BCED00; Thu, 28 Oct 2021 16:00:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: [PATCH v3] Bluetooth: btusb: Add support for variant WCN6855 by using different nvm From: Marcel Holtmann In-Reply-To: Date: Thu, 28 Oct 2021 16:00:21 +0200 Cc: tjiang@codeaurora.org, Johan Hedberg , Luiz Augusto von Dentz , Linux Kernel Mailing List , linux-bluetooth , MSM , Balakrishna Godavarthi , c-hbandi@codeaurora.org, Hemantg , Rocky Liao , zijuhu@codeaurora.org Content-Transfer-Encoding: 8BIT Message-Id: <68A15E46-C716-4324-8B5D-C71C9D2753C5@holtmann.org> References: <1d19afff955cdc8d47582297a26246d9@codeaurora.org> To: Matthias Kaehlcke X-Mailer: Apple Mail (2.3693.20.0.1.32) Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hi Matthias, >> the previous patch is submitted by zijun , as he is not working on this >> project, I take over his job, so can we assume abandon the previous patch, >> using my new patch ? thank you. >> regards. > > Your patch is clearly based on zijun's one, it even has the same subject. A > change of authorship shouldn't result in resetting the version number, it's > still the same patch/series. You can always add a 'Co-developed-by:' tag to > indicate that someone else contributed to a patch, or use a 'From:' tag if > you only made minor changes on top of someone else's work. I really don’t care much since that is for them and their company policy to figure out. > Not sure how to proceed best with the version number, especially since there > are already 3 versions of the 'new' patch. Either option can create confusion, > I guess you can continue with the new scheme, it seems the patch is almost > ready to land anyway. It is a total mess already for a dead simple patch like this. And they keep messing it up differently every time. I provided a btusb_generate_qca_nvm_name() in one of my replies, where the variant variable was declared without NULL assignment and the ram_version was converted from little endian in place. That was 28th of September and 4 patches later the patch is still not ready to be merged. The maintainer hands you the recipe and you still screw up the cake multiple times; I am just done with this. The next version would be a v16 btw. So seriously, how can we have 15 revisions so far and still not have this in a mergable state? Regards Marcel