Message ID | 20230303185351.2825900-1-usama.anjum@collabora.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp581908wrd; Fri, 3 Mar 2023 11:09:21 -0800 (PST) X-Google-Smtp-Source: AK7set+JzoVjeeocTQX8xVvGh8OSxJWWLd7Oujig3S6NmBFKU0o1GvZBsOZNPdVKE3Sp0j/5lep5 X-Received: by 2002:a17:907:9719:b0:895:ef96:9d9b with SMTP id jg25-20020a170907971900b00895ef969d9bmr3006203ejc.30.1677870561332; Fri, 03 Mar 2023 11:09:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677870561; cv=none; d=google.com; s=arc-20160816; b=BrjGcUKRix3tbQ2NhFyY8BXfkWu3pHpCn0OOs0QHIWwURlmdVIanfpq1TH2eA/K8cY V7c9QvWxflWiQo2Jl3gQ3IK2PZCicSLu29StoZrA38p1WyiMAabjUMGyfXXap7Vq+T9t ndvYKReYhG0BySJl0vyVPdl7utP+qW007LJNgLd+Sad+joDxACPlmJnLsl+FuI2oB3q2 itOu7YI9qhuiRp79GPByreJxM7W8gAVt2L8TnoKc39TQ8Kucxqy/AH9rGrHoy0Em2ii4 vbJMl5LE3Cm2F7oeNc7/qlN7p/y5ZesBwmayZZfBvfU0oAaIxzt+/t9cTyfjmbmPlP0g 9WIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=7EoUXbOThxaXhfyfddsQ6bIHGzKRrZG7/9aqIMgHY8U=; b=Nsu72s0uUJOigLaKslgxqErDmsBxQ7Z9/toPqmIWHoOG519JuVIbUhGrixoDaV1fcs 2Bm5q0cNKaD2n/hXt+VUU0v3niWWrmRzdO/LK9A18R65Qh04q6fRVmYzdIlGgBLblbtx RCdlLi10pApboS6eYz1go70E/yX0vMD2bGTXHE6K9MMp0ZcP6uRp1tc8W5PbJ9Vqz2uf WP9R60rQRcXSG4hu5/UYWbxMhBtaSTD1n/XtAcAWLorbRTZ4o2SJI4ts5njr38nwalZG zWFZlIQhd7B0S5apQ2kK86nN7n8sTBAfcua2/3Kr4TewNYARnqPnx5HqEclA4RwjbVZW 5YPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=DyTWu2Wi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d11-20020a170906640b00b008bdd66bbcb6si2309813ejm.323.2023.03.03.11.08.58; Fri, 03 Mar 2023 11:09:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=DyTWu2Wi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231383AbjCCSyp (ORCPT <rfc822;davidbtadokoro@gmail.com> + 99 others); Fri, 3 Mar 2023 13:54:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231583AbjCCSyn (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 3 Mar 2023 13:54:43 -0500 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5CA9415547; Fri, 3 Mar 2023 10:54:41 -0800 (PST) Received: from localhost.localdomain (unknown [182.179.171.187]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: usama.anjum) by madras.collabora.co.uk (Postfix) with ESMTPSA id 10E056602FB0; Fri, 3 Mar 2023 18:54:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1677869680; bh=kPAxGehnff6l8oiuJ40GvX3+I1+jtOiaN6I9cIx8lHA=; h=From:To:Cc:Subject:Date:From; b=DyTWu2Wi7OJw1mvphESD/xfp8/Q4+NTHe+WdERrupfbAS/71yjQ3fec98p/EvY0Nq sikW4CPnK65sWerRQQ5S8waLti0ICsNdkf9hmDOy8MxgPZN6tupfF+6eGfF5mFRUu3 M4e57x45BIvnuzMswkPzoFqi2WYklsQYsTAsZtl8vC78PwpWQD2AzpPknx/gs8o8rU mZ9DHi1o6zOrJc79x7bXhQwrDDXwB3ntfQ6ekUP/kYhMuDGUInm6RY3DW51hQP00bH y+yR/DBZlMRCqTflVBGDGLZlYJKcLcQvfP3c+WKl7bijLDj2XYavN3Moq6dice8lD3 Kpk6kjD/vQQCA== From: Muhammad Usama Anjum <usama.anjum@collabora.com> To: Ariel Elior <aelior@marvell.com>, Manish Chopra <manishc@marvell.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com> Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>, kernel@collabora.com, kernel-janitors@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] qede: remove linux/version.h and linux/compiler.h Date: Fri, 3 Mar 2023 23:53:50 +0500 Message-Id: <20230303185351.2825900-1-usama.anjum@collabora.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759374801890133644?= X-GMAIL-MSGID: =?utf-8?q?1759374801890133644?= |
Series |
[v2] qede: remove linux/version.h and linux/compiler.h
|
|
Commit Message
Muhammad Usama Anjum
March 3, 2023, 6:53 p.m. UTC
make versioncheck reports the following:
./drivers/net/ethernet/qlogic/qede/qede.h: 10 linux/version.h not needed.
./drivers/net/ethernet/qlogic/qede/qede_ethtool.c: 7 linux/version.h not needed.
So remove linux/version.h from both of these files. Also remove
linux/compiler.h while at it as it is also not being used.
Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
---
Changes since v1:
- Remove linux/compiler.h as well
---
drivers/net/ethernet/qlogic/qede/qede.h | 2 --
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 1 -
2 files changed, 3 deletions(-)
Comments
On Fri, 3 Mar 2023 23:53:50 +0500 Muhammad Usama Anjum wrote: > make versioncheck reports the following: > ./drivers/net/ethernet/qlogic/qede/qede.h: 10 linux/version.h not needed. > ./drivers/net/ethernet/qlogic/qede/qede_ethtool.c: 7 linux/version.h not needed. > > So remove linux/version.h from both of these files. Also remove > linux/compiler.h while at it as it is also not being used. > > Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> # Form letter - net-next is closed The merge window for v6.3 has begun and therefore net-next is closed for new drivers, features, code refactoring and optimizations. We are currently accepting bug fixes only. Please repost when net-next reopens after Mar 6th. RFC patches sent for review only are obviously welcome at any time.
On 3/4/23 4:54 AM, Jakub Kicinski wrote: > On Fri, 3 Mar 2023 23:53:50 +0500 Muhammad Usama Anjum wrote: >> make versioncheck reports the following: >> ./drivers/net/ethernet/qlogic/qede/qede.h: 10 linux/version.h not needed. >> ./drivers/net/ethernet/qlogic/qede/qede_ethtool.c: 7 linux/version.h not needed. >> >> So remove linux/version.h from both of these files. Also remove >> linux/compiler.h while at it as it is also not being used. >> >> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> > > # Form letter - net-next is closed > > The merge window for v6.3 has begun and therefore net-next is closed > for new drivers, features, code refactoring and optimizations. > We are currently accepting bug fixes only. > > Please repost when net-next reopens after Mar 6th. It is Mar 7th. Please review. > > RFC patches sent for review only are obviously welcome at any time.
On Tue, Mar 07, 2023 at 06:39:20PM +0500, Muhammad Usama Anjum wrote: > On 3/4/23 4:54 AM, Jakub Kicinski wrote: > > On Fri, 3 Mar 2023 23:53:50 +0500 Muhammad Usama Anjum wrote: > >> make versioncheck reports the following: > >> ./drivers/net/ethernet/qlogic/qede/qede.h: 10 linux/version.h not needed. > >> ./drivers/net/ethernet/qlogic/qede/qede_ethtool.c: 7 linux/version.h not needed. > >> > >> So remove linux/version.h from both of these files. Also remove > >> linux/compiler.h while at it as it is also not being used. > >> > >> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> > > > > # Form letter - net-next is closed > > > > The merge window for v6.3 has begun and therefore net-next is closed > > for new drivers, features, code refactoring and optimizations. > > We are currently accepting bug fixes only. > > > > Please repost when net-next reopens after Mar 6th. > It is Mar 7th. Please review. I think that the way it works is that you need to repost the patch. Probably with REPOST in the subject if it is unchanged: Subject: [PATCH net-next repost v2] ... Or bumped to v3 if there are changes. Subject: [PATCH net-next v3] ... Also, as per the examples above, the target tree, in this case 'net-next' should be included in the subject.
On 3/7/23 9:38 PM, Simon Horman wrote: > On Tue, Mar 07, 2023 at 06:39:20PM +0500, Muhammad Usama Anjum wrote: >> On 3/4/23 4:54 AM, Jakub Kicinski wrote: >>> On Fri, 3 Mar 2023 23:53:50 +0500 Muhammad Usama Anjum wrote: >>>> make versioncheck reports the following: >>>> ./drivers/net/ethernet/qlogic/qede/qede.h: 10 linux/version.h not needed. >>>> ./drivers/net/ethernet/qlogic/qede/qede_ethtool.c: 7 linux/version.h not needed. >>>> >>>> So remove linux/version.h from both of these files. Also remove >>>> linux/compiler.h while at it as it is also not being used. >>>> >>>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> >>> >>> # Form letter - net-next is closed >>> >>> The merge window for v6.3 has begun and therefore net-next is closed >>> for new drivers, features, code refactoring and optimizations. >>> We are currently accepting bug fixes only. >>> >>> Please repost when net-next reopens after Mar 6th. >> It is Mar 7th. Please review. > > I think that the way it works is that you need to repost the patch. > Probably with REPOST in the subject if it is unchanged:Sorry, I didn't know. I'll repost it. > > Subject: [PATCH net-next repost v2] ... > > Or bumped to v3 if there are changes. > > Subject: [PATCH net-next v3] ... > > Also, as per the examples above, the target tree, in this case > 'net-next' should be included in the subject. I don't know much about net tree and its location. This is why people use linux-next for sending patches. I'm not sure about the networking sub system. Would it be accepted if I send it against linux-next as in [PATCH linux-next repost v2]?
From: Muhammad Usama Anjum <usama.anjum@collabora.com> Date: Tue, 7 Mar 2023 21:53:48 +0500 > On 3/7/23 9:38 PM, Simon Horman wrote: >> On Tue, Mar 07, 2023 at 06:39:20PM +0500, Muhammad Usama Anjum wrote: >>> On 3/4/23 4:54 AM, Jakub Kicinski wrote: >>>> On Fri, 3 Mar 2023 23:53:50 +0500 Muhammad Usama Anjum wrote: >>>>> make versioncheck reports the following: >>>>> ./drivers/net/ethernet/qlogic/qede/qede.h: 10 linux/version.h not needed. >>>>> ./drivers/net/ethernet/qlogic/qede/qede_ethtool.c: 7 linux/version.h not needed. >>>>> >>>>> So remove linux/version.h from both of these files. Also remove >>>>> linux/compiler.h while at it as it is also not being used. >>>>> >>>>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> >>>> >>>> # Form letter - net-next is closed >>>> >>>> The merge window for v6.3 has begun and therefore net-next is closed >>>> for new drivers, features, code refactoring and optimizations. >>>> We are currently accepting bug fixes only. >>>> >>>> Please repost when net-next reopens after Mar 6th. >>> It is Mar 7th. Please review. >> >> I think that the way it works is that you need to repost the patch. >> Probably with REPOST in the subject if it is unchanged:Sorry, I didn't know. I'll repost it. > >> >> Subject: [PATCH net-next repost v2] ... >> >> Or bumped to v3 if there are changes. >> >> Subject: [PATCH net-next v3] ... >> >> Also, as per the examples above, the target tree, in this case >> 'net-next' should be included in the subject. > I don't know much about net tree and its location. This is why people use Here[0]. > linux-next for sending patches. I'm not sure about the networking sub No, people use the corresponding mailing lists to send and repositories to base their patches on. > system. Would it be accepted if I send it against linux-next as in [PATCH > linux-next repost v2]? No. Please use net-next I provided above. Your subject prefix will be [PATCH net-next v3] since you'll have changes (specifying the correct tree). You can ask git-format-patch to generate it automatically via `git format-patch --subject-prefix='PATCH net-next' -v3 ...` > > One more note: I was participating in reviewing/discussing your first patch version, so please add all the participants to --cc when you send next versions. For this particular patch it means Jakub, Simon and me must be specified explicitly in --cc when you send v3. [0] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/ Thanks, Olek
On Tue, Mar 07, 2023 at 06:13:16PM +0100, Alexander Lobakin wrote: > >> Also, as per the examples above, the target tree, in this case > >> 'net-next' should be included in the subject. > > I don't know much about net tree and its location. This is why people use > > Here[0]. > > > linux-next for sending patches. I'm not sure about the networking sub > > No, people use the corresponding mailing lists to send and repositories > to base their patches on. > This is only for networking. It affect BPF too, I suppose, but I always tell everyone to just send BPF bug reports instead of patches. I can keep track of linux-next, net and net-next. No one can keep track of all @#$@#$@#$@# 300+ trees. I really hate this networking requirement but I try really hard to get it right and still mess up half the time. regards, dan carpenter
On Mon, 13 Mar 2023 11:46:57 +0300 Dan Carpenter wrote: > This is only for networking. > > It affect BPF too, I suppose, but I always tell everyone to just send > BPF bug reports instead of patches. I can keep track of linux-next, net > and net-next. No one can keep track of all @#$@#$@#$@# 300+ trees. > > I really hate this networking requirement but I try really hard to get > it right and still mess up half the time. Don't worry about it too much, there needs to be a level of understanding for cross-tree folks. This unfortunately may not be afforded to less known developers.. because we don't know them/that they are working cross-tree. Reality check for me - this is really something that should be handled by our process scripts, right? get_maintainer/ /checkpatch ? Or that's not a fair expectation.
On Mon, Mar 13, 2023 at 11:45:38AM -0700, Jakub Kicinski wrote: > On Mon, 13 Mar 2023 11:46:57 +0300 Dan Carpenter wrote: > > This is only for networking. > > > > It affect BPF too, I suppose, but I always tell everyone to just send > > BPF bug reports instead of patches. I can keep track of linux-next, net > > and net-next. No one can keep track of all @#$@#$@#$@# 300+ trees. > > > > I really hate this networking requirement but I try really hard to get > > it right and still mess up half the time. > > Don't worry about it too much, there needs to be a level of > understanding for cross-tree folks. This unfortunately may > not be afforded to less known developers.. because we don't > know them/that they are working cross-tree. > > Reality check for me - this is really something that should > be handled by our process scripts, right? get_maintainer/ > /checkpatch ? Or that's not a fair expectation. I think that what we are seeing is friction introduced by our processes. I'd say that for those who spend time contributing to net-next/net on a regular basis, the friction is not great. The process is learnt. And for the most part followed. But for others, developers more focused on other parts of the Kernel, or otherwise contributing to net-next/net infrequently, the friction seems real. I do think tooling can help. But perhaps we can also explore other ways to reduce friction: * Aligning processes with those of other parts of the Kernel * Streamlining processes * providing an alternate path for contributions of the nature I described above. Just ideas, seeing as you asked.
On Mon, Mar 13, 2023 at 11:45:38AM -0700, Jakub Kicinski wrote: > Reality check for me - this is really something that should > be handled by our process scripts, right? get_maintainer/ > /checkpatch ? Or that's not a fair expectation. If it could be automated some way, that would help a lot. There are a bunch of things which have confused me in the past such as how RDMA and the net trees interact. Also the Mellanox tree, I used to think Mellanox maintainers collect patches and send git pulls but apparently for fixes they prefer if you collect them from mailing list? I'm looking at my process now and I can see that I was dumb when I set this up. Just doing a fetch and switching between git trees was taking 4 minutes but I can cut it down to 30 seconds. So some of this was my fault. regards, dan carpenter
diff --git a/drivers/net/ethernet/qlogic/qede/qede.h b/drivers/net/ethernet/qlogic/qede/qede.h index f90dcfe9ee68..f9931ecb7baa 100644 --- a/drivers/net/ethernet/qlogic/qede/qede.h +++ b/drivers/net/ethernet/qlogic/qede/qede.h @@ -6,8 +6,6 @@ #ifndef _QEDE_H_ #define _QEDE_H_ -#include <linux/compiler.h> -#include <linux/version.h> #include <linux/workqueue.h> #include <linux/netdevice.h> #include <linux/interrupt.h> diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c index 8034d812d5a0..374a86b875a3 100644 --- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c +++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c @@ -4,7 +4,6 @@ * Copyright (c) 2019-2020 Marvell International Ltd. */ -#include <linux/version.h> #include <linux/types.h> #include <linux/netdevice.h> #include <linux/etherdevice.h>