From: Greg KH <gregkh@linuxfoundation.org> To: Leon Romanovsky <leon@kernel.org> Cc: Selvin Xavier <selvin.xavier@broadcom.com>, linux-rdma@vger.kernel.org, dledford@redhat.com, jgg@ziepe.ca, linux-nvme@lists.infradead.org, stable@vger.kernel.org, Parav Pandit <parav@mellanox.com> Subject: Re: [PATCH for-rc] RDMA/bnxt_re: Honor vlan_id in GID entry comparison Date: Tue, 16 Jul 2019 18:58:52 +0900 [thread overview] Message-ID: <20190716095852.GA25228@kroah.com> (raw) In-Reply-To: <20190716095007.GK10130@mtr-leonro.mtl.com> On Tue, Jul 16, 2019 at 12:50:07PM +0300, Leon Romanovsky wrote: > 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: <stable@vger.kernel.org> # v5.2+ > > > > > > Reported-by: Yi Zhang <yi.zhang@redhat.com> > > > > > > > > > > > Co-developed-by: Parav Pandit <parav@mellanox.com> > > > > > > Signed-off-by: Parav Pandit <parav@mellanox.com> > > > > > > > > > > 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. That's up to you, and your fellow co-authors to decide. > > 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? Because we have had some patches where it really was a work of multiple people and it is good to show the correct authorship wherever possible. If you look, this tag was added based on a document in the kernel tree that Thomas and I worked on together and we both wanted the "blame" for it :) > > 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. Oh come on, this is about the ability to give people credit where they did not have it before. It's not about being "compliant", it's about being "nice" and "fair". Something that no one should complain about. There is no one forcing you to add this tag to patches with your name on it if you do not want to. But for those who work on changes together, it is important to give them that type of credit. thanks, greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: gregkh@linuxfoundation.org (Greg KH) Subject: [PATCH for-rc] RDMA/bnxt_re: Honor vlan_id in GID entry comparison Date: Tue, 16 Jul 2019 18:58:52 +0900 [thread overview] Message-ID: <20190716095852.GA25228@kroah.com> (raw) In-Reply-To: <20190716095007.GK10130@mtr-leonro.mtl.com> On Tue, Jul 16, 2019@12:50:07PM +0300, Leon Romanovsky wrote: > On Tue, Jul 16, 2019@06:09:17PM +0900, Greg KH wrote: > > On Tue, Jul 16, 2019@11:41:26AM +0300, Leon Romanovsky wrote: > > > On Tue, Jul 16, 2019@04:16:44PM +0900, Greg KH wrote: > > > > On Tue, Jul 16, 2019@10:10:30AM +0300, Leon Romanovsky wrote: > > > > > On Mon, Jul 15, 2019@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: <stable at vger.kernel.org> # v5.2+ > > > > > > Reported-by: Yi Zhang <yi.zhang at redhat.com> > > > > > > > > > > > Co-developed-by: Parav Pandit <parav at mellanox.com> > > > > > > Signed-off-by: Parav Pandit <parav at mellanox.com> > > > > > > > > > > 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. That's up to you, and your fellow co-authors to decide. > > 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? Because we have had some patches where it really was a work of multiple people and it is good to show the correct authorship wherever possible. If you look, this tag was added based on a document in the kernel tree that Thomas and I worked on together and we both wanted the "blame" for it :) > > 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. Oh come on, this is about the ability to give people credit where they did not have it before. It's not about being "compliant", it's about being "nice" and "fair". Something that no one should complain about. There is no one forcing you to add this tag to patches with your name on it if you do not want to. But for those who work on changes together, it is important to give them that type of credit. thanks, greg k-h
next prev parent reply other threads:[~2019-07-16 9:58 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-15 9:19 [PATCH for-rc] RDMA/bnxt_re: Honor vlan_id in GID entry comparison Selvin Xavier 2019-07-15 9:19 ` Selvin Xavier 2019-07-15 14:17 ` Yi Zhang 2019-07-15 14:17 ` Yi Zhang 2019-07-16 7:10 ` Leon Romanovsky 2019-07-16 7:10 ` Leon Romanovsky 2019-07-16 7:16 ` Greg KH 2019-07-16 7:16 ` Greg KH 2019-07-16 8:41 ` Leon Romanovsky 2019-07-16 8:41 ` Leon Romanovsky 2019-07-16 9:09 ` Greg KH 2019-07-16 9:09 ` Greg KH 2019-07-16 9:50 ` Leon Romanovsky 2019-07-16 9:50 ` Leon Romanovsky 2019-07-16 9:58 ` Greg KH [this message] 2019-07-16 9:58 ` Greg KH 2019-07-16 10:20 ` Leon Romanovsky 2019-07-16 10:20 ` Leon Romanovsky 2019-07-22 18:07 ` Jason Gunthorpe 2019-07-22 18:07 ` Jason Gunthorpe
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190716095852.GA25228@kroah.com \ --to=gregkh@linuxfoundation.org \ --cc=dledford@redhat.com \ --cc=jgg@ziepe.ca \ --cc=leon@kernel.org \ --cc=linux-nvme@lists.infradead.org \ --cc=linux-rdma@vger.kernel.org \ --cc=parav@mellanox.com \ --cc=selvin.xavier@broadcom.com \ --cc=stable@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.