Message ID | 20230303185351.2825900-1-usama.anjum@collabora.com (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | [v2] qede: remove linux/version.h and linux/compiler.h | expand |
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>
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(-)