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 <[email protected]>
---
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(-)
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>
--
2.39.2
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 <[email protected]>
# 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 <[email protected]>
>
> # 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.
--
BR,
Muhammad Usama Anjum
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 <[email protected]>
> >
> > # 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 <[email protected]>
>>>
>>> # 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]?
--
BR,
Muhammad Usama Anjum
From: Muhammad Usama Anjum <[email protected]>
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 <[email protected]>
>>>>
>>>> # 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