Fix en_rx.c:687:1-17: WARNING: Assignment of 0/1 to bool variable
Fix main.c:4465:5-13: WARNING: Comparison of 0/1 to bool variable
Signed-off-by: Vasyl Gomonovych <[email protected]>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 502d1b97855c..b0f79a5151cf 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -684,7 +684,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
xdp_prog = rcu_dereference(ring->xdp_prog);
xdp.rxq = &ring->xdp_rxq;
xdp.frame_sz = priv->frag_info[0].frag_stride;
- doorbell_pending = 0;
+ doorbell_pending = false;
/* We assume a 1:1 mapping between CQEs and Rx descriptors, so Rx
* descriptor offset can be deduced from the CQE index instead of
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index c326b434734e..c5bce3eeed91 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -4462,7 +4462,7 @@ static int __init mlx4_verify_params(void)
pr_warn("mlx4_core: log_num_vlan - obsolete module param, using %d\n",
MLX4_LOG_NUM_VLANS);
- if (use_prio != 0)
+ if (use_prio != false)
pr_warn("mlx4_core: use_prio - obsolete module param, ignored\n");
if ((log_mtts_per_seg < 0) || (log_mtts_per_seg > 7)) {
--
2.17.1
On Fri, 11 Dec 2020 11:05:18 +0100 Vasyl Gomonovych wrote:
> Fix en_rx.c:687:1-17: WARNING: Assignment of 0/1 to bool variable
> Fix main.c:4465:5-13: WARNING: Comparison of 0/1 to bool variable
Apart from addressing Joe's comment please name the tool which produced
those.
On Fri, 2020-12-11 at 11:05 +0100, Vasyl Gomonovych wrote:
> Fix en_rx.c:687:1-17: WARNING: Assignment of 0/1 to bool variable
> Fix main.c:4465:5-13: WARNING: Comparison of 0/1 to bool variable
[]
> diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
[]
> @@ -4462,7 +4462,7 @@ static int __init mlx4_verify_params(void)
> ? pr_warn("mlx4_core: log_num_vlan - obsolete module param, using %d\n",
> ? MLX4_LOG_NUM_VLANS);
> ?
>
> - if (use_prio != 0)
> + if (use_prio != false)
> ? pr_warn("mlx4_core: use_prio - obsolete module param, ignored\n");
Generally, assuming use_prio is bool, this would?be written
if (use_prio)
pr_warn("etc...")
It is fix for semantic patch warning available in
scripts/coccinelle/misc/boolinit.cocci
Fix en_rx.c:687:1-17: WARNING: Assignment of 0/1 to bool variable
Fix main.c:4465:5-13: WARNING: Comparison of 0/1 to bool variable
Signed-off-by: Vasyl Gomonovych <[email protected]>
---
- Add coccicheck script name
- Simplify if condition
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 502d1b97855c..b0f79a5151cf 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -684,7 +684,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
xdp_prog = rcu_dereference(ring->xdp_prog);
xdp.rxq = &ring->xdp_rxq;
xdp.frame_sz = priv->frag_info[0].frag_stride;
- doorbell_pending = 0;
+ doorbell_pending = false;
/* We assume a 1:1 mapping between CQEs and Rx descriptors, so Rx
* descriptor offset can be deduced from the CQE index instead of
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index c326b434734e..3492a4f3691e 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -4462,7 +4462,7 @@ static int __init mlx4_verify_params(void)
pr_warn("mlx4_core: log_num_vlan - obsolete module param, using %d\n",
MLX4_LOG_NUM_VLANS);
- if (use_prio != 0)
+ if (use_prio)
pr_warn("mlx4_core: use_prio - obsolete module param, ignored\n");
if ((log_mtts_per_seg < 0) || (log_mtts_per_seg > 7)) {
--
2.17.1
On Mon, Dec 14, 2020 at 11:30:08AM +0100, Vasyl Gomonovych wrote:
> It is fix for semantic patch warning available in
> scripts/coccinelle/misc/boolinit.cocci
> Fix en_rx.c:687:1-17: WARNING: Assignment of 0/1 to bool variable
> Fix main.c:4465:5-13: WARNING: Comparison of 0/1 to bool variable
>
> Signed-off-by: Vasyl Gomonovych <[email protected]>
> ---
> - Add coccicheck script name
> - Simplify if condition
> ---
> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/main.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Please refrain from sending new version of patches as reply-to to
previous variants. It makes to appear previous patches out-of-order
while viewing in threaded mode.
Thanks
On Mon, 14 Dec 2020 13:16:08 +0200 Leon Romanovsky wrote:
> On Mon, Dec 14, 2020 at 11:30:08AM +0100, Vasyl Gomonovych wrote:
> > It is fix for semantic patch warning available in
> > scripts/coccinelle/misc/boolinit.cocci
> > Fix en_rx.c:687:1-17: WARNING: Assignment of 0/1 to bool variable
> > Fix main.c:4465:5-13: WARNING: Comparison of 0/1 to bool variable
> >
> > Signed-off-by: Vasyl Gomonovych <[email protected]>
> > ---
> > - Add coccicheck script name
> > - Simplify if condition
> > ---
> > drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
> > drivers/net/ethernet/mellanox/mlx4/main.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
>
> Please refrain from sending new version of patches as reply-to to
> previous variants. It makes to appear previous patches out-of-order
> while viewing in threaded mode.
Yes, please! I'm glad I'm not the only one who feels this way! :)
On Mon, 2020-12-14 at 11:03 -0800, Jakub Kicinski wrote:
> On Mon, 14 Dec 2020 13:16:08 +0200 Leon Romanovsky wrote:
> > On Mon, Dec 14, 2020 at 11:30:08AM +0100, Vasyl Gomonovych wrote:
> > > It is fix for semantic patch warning available in
> > > scripts/coccinelle/misc/boolinit.cocci
> > > Fix en_rx.c:687:1-17: WARNING: Assignment of 0/1 to bool variable
> > > Fix main.c:4465:5-13: WARNING: Comparison of 0/1 to bool variable
> > >
> > > Signed-off-by: Vasyl Gomonovych <[email protected]>
> > > ---
> > > ?- Add coccicheck script name
> > > ?- Simplify if condition
> > > ---
> > > ?drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
> > > ?drivers/net/ethernet/mellanox/mlx4/main.c | 2 +-
> > > ?2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > Please refrain from sending new version of patches as reply-to to
> > previous variants. It makes to appear previous patches out-of-order
> > while viewing in threaded mode.
>
> Yes, please! I'm glad I'm not the only one who feels this way! :)
I'm the other way.
I prefer revisions to single patches (as opposed to large patch series)
in the same thread.
There is no other easy way for changes to a patch to be tracked AFAIK.
Most email clients use both In-Reply-To: and References: headers as
the mechanism to thread replies.
Keeping the latest messages at the bottom of a thread works well
to see revision sequences.
On Mon, 14 Dec 2020 11:30:08 +0100 Vasyl Gomonovych wrote:
> It is fix for semantic patch warning available in
> scripts/coccinelle/misc/boolinit.cocci
> Fix en_rx.c:687:1-17: WARNING: Assignment of 0/1 to bool variable
> Fix main.c:4465:5-13: WARNING: Comparison of 0/1 to bool variable
>
> Signed-off-by: Vasyl Gomonovych <[email protected]>
Looks like it doesn't apply to net-next, please respin based on:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/
On Tue, 2020-12-15 at 07:18 +0200, Leon Romanovsky wrote:
> On Mon, Dec 14, 2020 at 11:15:01AM -0800, Joe Perches wrote:
> > I prefer revisions to single patches (as opposed to large patch series)
> > in the same thread.
>
> It depends which side you are in that game. From the reviewer point of
> view, such submission breaks flow very badly. It unfolds the already
> reviewed thread, messes with the order and many more little annoying
> things.
This is where I disagree with you. I am a reviewer here.
Not having context to be able to inspect vN -> vN+1 is made
more difficult not having the original patch available and
having to search history for it.
Almost no one adds URL links to older submissions below the ---.
Were that a standard mechanism below the --- line, then it would
be OK.
On Mon, Dec 14, 2020 at 11:15:01AM -0800, Joe Perches wrote:
> On Mon, 2020-12-14 at 11:03 -0800, Jakub Kicinski wrote:
> > On Mon, 14 Dec 2020 13:16:08 +0200 Leon Romanovsky wrote:
> > > On Mon, Dec 14, 2020 at 11:30:08AM +0100, Vasyl Gomonovych wrote:
> > > > It is fix for semantic patch warning available in
> > > > scripts/coccinelle/misc/boolinit.cocci
> > > > Fix en_rx.c:687:1-17: WARNING: Assignment of 0/1 to bool variable
> > > > Fix main.c:4465:5-13: WARNING: Comparison of 0/1 to bool variable
> > > >
> > > > Signed-off-by: Vasyl Gomonovych <[email protected]>
> > > > ---
> > > > ?- Add coccicheck script name
> > > > ?- Simplify if condition
> > > > ---
> > > > ?drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
> > > > ?drivers/net/ethernet/mellanox/mlx4/main.c | 2 +-
> > > > ?2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > Please refrain from sending new version of patches as reply-to to
> > > previous variants. It makes to appear previous patches out-of-order
> > > while viewing in threaded mode.
> >
> > Yes, please! I'm glad I'm not the only one who feels this way! :)
>
> I'm the other way.
>
> I prefer revisions to single patches (as opposed to large patch series)
> in the same thread.
It depends which side you are in that game. From the reviewer point of
view, such submission breaks flow very badly. It unfolds the already
reviewed thread, messes with the order and many more little annoying
things.
>
> There is no other easy way for changes to a patch to be tracked AFAIK.
Not really, I'm using very simple convention to keep tracking of
changes. The changelog together with lorifier does the trick.
https://github.com/danrue/lorifier
https://lore.kernel.org/linux-rdma/[email protected]/
So I'm simply adding link to the previous version when sending new one.
>
> Most email clients use both In-Reply-To: and References: headers as
> the mechanism to thread replies.
Right, and this is exactly what we don't want for vX patches.
>
> Keeping the latest messages at the bottom of a thread works well
> to see revision sequences.
I have a different workflow.
Thanks
On Mon, Dec 14, 2020 at 09:37:34PM -0800, Joe Perches wrote:
> On Tue, 2020-12-15 at 07:18 +0200, Leon Romanovsky wrote:
> > On Mon, Dec 14, 2020 at 11:15:01AM -0800, Joe Perches wrote:
> > > I prefer revisions to single patches (as opposed to large patch series)
> > > in the same thread.
> >
> > It depends which side you are in that game. From the reviewer point of
> > view, such submission breaks flow very badly. It unfolds the already
> > reviewed thread, messes with the order and many more little annoying
> > things.
>
> This is where I disagree with you. I am a reviewer here.
It is ok, different people have different views.
>
> Not having context to be able to inspect vN -> vN+1 is made
> more difficult not having the original patch available and
> having to search history for it.
I'm following after specific subsystems and see all patches there,
so for me and Jakub context already exists.
Bottom line, it depends on the workflow.
>
> Almost no one adds URL links to older submissions below the ---.
Too bad, maybe it is time to enforce it.
>
> Were that a standard mechanism below the --- line, then it would
> be OK.
So let's me summarize, we (RDMA and netdev subsystems) would like to ask
do not submit new patch revisions as reply-to.
Thanks
Hi,
Ouuu it was fixed recently in net-next.
Sorry, I missed that.
Thanks for submitting policy clarification I am going to adapt to it.
Thanks
On Tue, Dec 15, 2020 at 7:18 AM Leon Romanovsky <[email protected]> wrote:
>
> On Mon, Dec 14, 2020 at 09:37:34PM -0800, Joe Perches wrote:
> > On Tue, 2020-12-15 at 07:18 +0200, Leon Romanovsky wrote:
> > > On Mon, Dec 14, 2020 at 11:15:01AM -0800, Joe Perches wrote:
> > > > I prefer revisions to single patches (as opposed to large patch series)
> > > > in the same thread.
> > >
> > > It depends which side you are in that game. From the reviewer point of
> > > view, such submission breaks flow very badly. It unfolds the already
> > > reviewed thread, messes with the order and many more little annoying
> > > things.
> >
> > This is where I disagree with you. I am a reviewer here.
>
> It is ok, different people have different views.
>
> >
> > Not having context to be able to inspect vN -> vN+1 is made
> > more difficult not having the original patch available and
> > having to search history for it.
>
> I'm following after specific subsystems and see all patches there,
> so for me and Jakub context already exists.
>
> Bottom line, it depends on the workflow.
>
> >
> > Almost no one adds URL links to older submissions below the ---.
>
> Too bad, maybe it is time to enforce it.
>
> >
> > Were that a standard mechanism below the --- line, then it would
> > be OK.
>
> So let's me summarize, we (RDMA and netdev subsystems) would like to ask
> do not submit new patch revisions as reply-to.
>
> Thanks
--
Доброї вам пори дня.