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 X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5186FC76195 for ; Tue, 16 Jul 2019 09:50:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2B9F520665 for ; Tue, 16 Jul 2019 09:50:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563270613; bh=dpskP48dz6L7doFCtp7W3zMbv4orWk6GK6O1TLm70Ho=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=v3ihM/Neks3/VINGaXl5qQ/PbbSChsstmp8LBsKn2z+O6gW4p/mZDKwexZKCirgsk 3qTxj8sP9TlUKXxrzZDkyder6VbPnR/zKMwrIi8ueMNxouydxpdFyGidnzuc8u6zMW rn7bHmlHq5lm66VKeErP48GtARL2nhr8RjsU8CDI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731896AbfGPJuM (ORCPT ); Tue, 16 Jul 2019 05:50:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:37538 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731015AbfGPJuM (ORCPT ); Tue, 16 Jul 2019 05:50:12 -0400 Received: from localhost (unknown [193.47.165.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 77ABA2064B; Tue, 16 Jul 2019 09:50:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563270611; bh=dpskP48dz6L7doFCtp7W3zMbv4orWk6GK6O1TLm70Ho=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XZ4atqxgtDuxqVXzfF/P0bRMCMXA22maqJlIV1Mak9/t/65wY4p2uRpH71/gCB4BN GzMcK90E6j8KbxVQ6jaEDLRBGFw1FKjuVAix6Y7mX4RkqMoJYmf7Ks3TdFLfjRRcRj fHGreQf+rH5iGv2jOwfUgbiBWqeioNyFxMBx1PfQ= Date: Tue, 16 Jul 2019 12:50:07 +0300 From: Leon Romanovsky To: Greg KH Cc: Selvin Xavier , linux-rdma@vger.kernel.org, dledford@redhat.com, jgg@ziepe.ca, linux-nvme@lists.infradead.org, stable@vger.kernel.org, Parav Pandit Subject: Re: [PATCH for-rc] RDMA/bnxt_re: Honor vlan_id in GID entry comparison Message-ID: <20190716095007.GK10130@mtr-leonro.mtl.com> References: <20190715091913.15726-1-selvin.xavier@broadcom.com> <20190716071030.GH10130@mtr-leonro.mtl.com> <20190716071644.GA21780@kroah.com> <20190716084126.GJ10130@mtr-leonro.mtl.com> <20190716090917.GA11964@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190716090917.GA11964@kroah.com> User-Agent: Mutt/1.12.0 (2019-05-25) Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Tue, Jul 16, 2019 at 06:09:17PM +0900, Greg KH wrote: > On Tue, Jul 16, 2019 at 11:41:26AM +0300, Leon Romanovsky wrote: > > On Tue, Jul 16, 2019 at 04:16:44PM +0900, Greg KH wrote: > > > On Tue, Jul 16, 2019 at 10:10:30AM +0300, Leon Romanovsky wrote: > > > > On Mon, Jul 15, 2019 at 05:19:13AM -0400, Selvin Xavier wrote: > > > > > GID entry consist of GID, vlan, netdev and smac. > > > > > Extend GID duplicate check companions to consider vlan_id as well > > > > > to support IPv6 VLAN based link local addresses. Introduce > > > > > a new structure (bnxt_qplib_gid_info) to hold gid and vlan_id information. > > > > > > > > > > The issue is discussed in the following thread > > > > > https://www.spinics.net/lists/linux-rdma/msg81594.html > > > > > > > > > > Fixes: 823b23da7113 ("IB/core: Allow vlan link local address based RoCE GIDs") > > > > > Cc: # v5.2+ > > > > > Reported-by: Yi Zhang > > > > > > > > > Co-developed-by: Parav Pandit > > > > > Signed-off-by: Parav Pandit > > > > > > > > I never understood why bad habits are so stinky. > > > > > > > > Can you please explain us what does it mean Co-developed-by and > > > > Signed-off-by of the same person in the same patch? > > > > > > See Documentation/process/submitting-patches.rst for what that tag > > > means. > > > > Read it, it doesn't help me to understand if I should now add > > Co-developed-by tag to most of RDMA Mellanox upstreamed patches, > > which already care my Signed-off-by, because I'm changing and fixing > > them many times. > > It depends, it's your call, if you think you deserve the credit, sure, > add it. If you are just doing basic "review" where you tell people what > needs to be done better, that's probably not what you need to do here. I'll probably not use this and not because I don't deserve credit, but because it looks ridiculously to me to see my name repeated N times for my work. > > One example, where I just added myself to a patch happened last week > where the developer submitted one solution, I took it and rewrote the > whole implementation (from raw kobjects to using the driver model). The > original author got the "From:" and I got a Co-developed-by line. In old days, we simply changed Author field if changes were above some arbitrary threshold (usually half of the original patch) and added SOB. Why wasn't this approach enough? > > Does that help? Yes, and it makes me wonder when we will need to hire compliance officer who will review all our upstreamed patches to comply with more and more bureaucracy. Thanks. > > thanks, > > greg k-h