| Message ID | 20201211100518.29804-1-gomonovych@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | net/mlx4: Use true,false for bool variable | expand |
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...")
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 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 <gomonovych@gmail.com> > --- > - 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 <gomonovych@gmail.com> > > --- > > - 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 <gomonovych@gmail.com> > > > --- > > > - 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 <gomonovych@gmail.com> 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 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 <gomonovych@gmail.com> > > > > --- > > > > - 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/20201125064628.8431-1-leon@kernel.org/ 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 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 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 <leon@kernel.org> 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 -- Доброї вам пори дня.
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)) {
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 <gomonovych@gmail.com> --- drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +- drivers/net/ethernet/mellanox/mlx4/main.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)