| Message ID | 20220324072607.63594-1-jakobkoschel@gmail.com (mailing list archive) |
|---|---|
| State | Deferred |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | taprio: replace usage of found with dedicated list iterator variable | expand |
Hi, Jakob Koschel <jakobkoschel@gmail.com> writes: > To move the list iterator variable into the list_for_each_entry_*() > macro in the future it should be avoided to use the list iterator > variable after the loop body. > > To *never* use the list iterator variable after the loop it was > concluded to use a separate iterator variable instead of a > found boolean [1]. > > This removes the need to use a found variable and simply checking if > the variable was set, can determine if the break/goto was hit. > > Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ > Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> > --- Code wise, patch look good. Just some commit style/meta comments: - I think that it would make more sense that these were two separate patches, but I haven't been following the fallout of the discussion above to know what other folks are doing; - Please use '[PATCH net-next]' in the subject prefix of your patch(es) when you next propose this (net-next is closed for new submissions for now, it should open again in a few days); Cheers,
> On 31. Mar 2022, at 01:15, Vinicius Costa Gomes <vinicius.gomes@intel.com> wrote: > > Hi, > > Jakob Koschel <jakobkoschel@gmail.com> writes: > >> To move the list iterator variable into the list_for_each_entry_*() >> macro in the future it should be avoided to use the list iterator >> variable after the loop body. >> >> To *never* use the list iterator variable after the loop it was >> concluded to use a separate iterator variable instead of a >> found boolean [1]. >> >> This removes the need to use a found variable and simply checking if >> the variable was set, can determine if the break/goto was hit. >> >> Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ >> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> >> --- > > Code wise, patch look good. > > Just some commit style/meta comments: > - I think that it would make more sense that these were two separate > patches, but I haven't been following the fallout of the discussion > above to know what other folks are doing; Thanks for the input, I'll split them up. > - Please use '[PATCH net-next]' in the subject prefix of your patch(es) > when you next propose this (net-next is closed for new submissions for > now, it should open again in a few days); I'll include that prefix, thanks. Paolo Abeni [CC'd] suggested to bundle all net-next patches in one series [1]. If that's the general desire I'm happy to do that. [1] https://lore.kernel.org/linux-kernel/7393b673c626fd75f2b4f8509faa5459254fb87c.camel@redhat.com/ > > > Cheers, > -- > Vinicius
Jakob Koschel <jakobkoschel@gmail.com> writes: >> On 31. Mar 2022, at 01:15, Vinicius Costa Gomes <vinicius.gomes@intel.com> wrote: >> >> Hi, >> >> Jakob Koschel <jakobkoschel@gmail.com> writes: >> >>> To move the list iterator variable into the list_for_each_entry_*() >>> macro in the future it should be avoided to use the list iterator >>> variable after the loop body. >>> >>> To *never* use the list iterator variable after the loop it was >>> concluded to use a separate iterator variable instead of a >>> found boolean [1]. >>> >>> This removes the need to use a found variable and simply checking if >>> the variable was set, can determine if the break/goto was hit. >>> >>> Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ >>> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> >>> --- >> >> Code wise, patch look good. >> >> Just some commit style/meta comments: >> - I think that it would make more sense that these were two separate >> patches, but I haven't been following the fallout of the discussion >> above to know what other folks are doing; > > Thanks for the input, I'll split them up. > >> - Please use '[PATCH net-next]' in the subject prefix of your patch(es) >> when you next propose this (net-next is closed for new submissions for >> now, it should open again in a few days); > > I'll include that prefix, thanks. > > Paolo Abeni [CC'd] suggested to bundle all net-next patches in one series [1]. > If that's the general desire I'm happy to do that. I agree with that, having one series for the whole net-next is going to be easier for everyone. Cheers,
Hi, > On 31. Mar 2022, at 19:58, Vinicius Costa Gomes <vinicius.gomes@intel.com> wrote: > > Jakob Koschel <jakobkoschel@gmail.com> writes: > >>> On 31. Mar 2022, at 01:15, Vinicius Costa Gomes <vinicius.gomes@intel.com> wrote: >>> >>> Hi, >>> >>> Jakob Koschel <jakobkoschel@gmail.com> writes: >>> >>>> To move the list iterator variable into the list_for_each_entry_*() >>>> macro in the future it should be avoided to use the list iterator >>>> variable after the loop body. >>>> >>>> To *never* use the list iterator variable after the loop it was >>>> concluded to use a separate iterator variable instead of a >>>> found boolean [1]. >>>> >>>> This removes the need to use a found variable and simply checking if >>>> the variable was set, can determine if the break/goto was hit. >>>> >>>> Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ >>>> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> >>>> --- >>> >>> Code wise, patch look good. >>> >>> Just some commit style/meta comments: >>> - I think that it would make more sense that these were two separate >>> patches, but I haven't been following the fallout of the discussion >>> above to know what other folks are doing; >> >> Thanks for the input, I'll split them up. >> >>> - Please use '[PATCH net-next]' in the subject prefix of your patch(es) >>> when you next propose this (net-next is closed for new submissions for >>> now, it should open again in a few days); >> >> I'll include that prefix, thanks. >> >> Paolo Abeni [CC'd] suggested to bundle all net-next patches in one series [1]. >> If that's the general desire I'm happy to do that. > > I agree with that, having one series for the whole net-next is going to > be easier for everyone. I have all the net-next patches bundled in one series now ready to repost. Just wanted to verify that's the intended format since it grew a bit larger then what was posted so far. It's 46 patches changing 51 files across all those files: drivers/connector/cn_queue.c | 13 ++++++------- drivers/net/dsa/mv88e6xxx/chip.c | 21 ++++++++++----------- drivers/net/dsa/sja1105/sja1105_vl.c | 14 +++++++++----- drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 3 ++- drivers/net/ethernet/intel/i40e/i40e_main.c | 24 ++++++++++++++---------- drivers/net/ethernet/mellanox/mlx4/alloc.c | 29 +++++++++++++++++++---------- drivers/net/ethernet/mellanox/mlx4/mcg.c | 17 ++++++++--------- drivers/net/ethernet/mellanox/mlx5/core/eq.c | 10 +++++++--- drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 12 ++++++------ drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c | 21 ++++++++++++--------- drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c | 7 +++++-- drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c | 12 +++++++++--- drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c | 25 ++++++++++++------------- drivers/net/ethernet/qlogic/qed/qed_dev.c | 11 ++++++----- drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 26 ++++++++++++-------------- drivers/net/ethernet/qlogic/qed/qed_spq.c | 6 +++--- drivers/net/ethernet/qlogic/qede/qede_filter.c | 11 +++++++---- drivers/net/ethernet/qlogic/qede/qede_rdma.c | 11 +++++------ drivers/net/ethernet/sfc/rx_common.c | 6 ++++-- drivers/net/ethernet/ti/netcp_core.c | 24 ++++++++++++++++-------- drivers/net/ethernet/toshiba/ps3_gelic_wireless.c | 30 +++++++++++++++--------------- drivers/net/ipvlan/ipvlan_main.c | 7 +++++-- drivers/net/rionet.c | 14 +++++++------- drivers/net/team/team.c | 20 +++++++++++++------- drivers/net/wireless/ath/ath10k/mac.c | 19 ++++++++++--------- drivers/net/wireless/ath/ath11k/dp_rx.c | 15 +++++++-------- drivers/net/wireless/ath/ath11k/wmi.c | 11 +++++------ drivers/net/wireless/ath/ath6kl/htc_mbox.c | 2 +- drivers/net/wireless/intel/ipw2x00/libipw_rx.c | 14 ++++++++------ drivers/rapidio/devices/rio_mport_cdev.c | 42 ++++++++++++++++++++---------------------- drivers/rapidio/devices/tsi721.c | 13 ++++++------- drivers/rapidio/rio.c | 14 +++++++------- drivers/rapidio/rio_cm.c | 81 +++++++++++++++++++++++++++++++++++++ net/9p/trans_virtio.c | 15 +++++++-------- net/9p/trans_xen.c | 10 ++++++---- net/core/devlink.c | 22 +++++++++++++++------- net/core/gro.c | 12 ++++++++---- net/dsa/dsa.c | 11 +++++------ net/ieee802154/core.c | 7 +++++-- net/ipv4/udp_tunnel_nic.c | 10 ++++++---- net/mac80211/offchannel.c | 28 ++++++++++++++-------------- net/mac80211/util.c | 7 +++++-- net/sched/sch_cbs.c | 11 +++++------ net/sched/sch_taprio.c | 11 +++++------ net/smc/smc_ism.c | 14 +++++++------- net/tipc/group.c | 12 ++++++++---- net/tipc/monitor.c | 21 ++++++++++++++------- net/tipc/name_table.c | 11 +++++++---- net/tipc/socket.c | 11 +++++++---- net/wireless/core.c | 7 +++++-- net/xfrm/xfrm_ipcomp.c | 11 +++++++---- 51 files changed, 452 insertions(+), 364 deletions(-) Please let me know if I should split it up or if there are certain files that might not fit. Otherwise I'll post them beginning of next week. > > > Cheers, > -- > Vinicius Thanks, Jakob
On Sun, 3 Apr 2022 13:53:06 +0200 Jakob Koschel wrote: > I have all the net-next patches bundled in one series now ready to repost. > Just wanted to verify that's the intended format since it grew a bit larger > then what was posted so far. > > It's 46 patches changing 51 files across all those files: Thanks for asking, we have a limit of 15 patches per series to avoid overloading reviewers. But the patches will likely get merged rather quickly so it won't be a long wait before you can send another series. That said: > drivers/connector/cn_queue.c | 13 ++++++------- > drivers/net/dsa/mv88e6xxx/chip.c | 21 ++++++++++----------- > drivers/net/dsa/sja1105/sja1105_vl.c | 14 +++++++++----- yup, that's net-next > drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 3 ++- > drivers/net/ethernet/intel/i40e/i40e_main.c | 24 ++++++++++++++---------- > drivers/net/ethernet/mellanox/mlx4/alloc.c | 29 +++++++++++++++++++---------- > drivers/net/ethernet/mellanox/mlx4/mcg.c | 17 ++++++++--------- > drivers/net/ethernet/mellanox/mlx5/core/eq.c | 10 +++++++--- > drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 12 ++++++------ > drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c | 21 ++++++++++++--------- > drivers/net/ethernet/mellanox/mlxsw/spectrum_fid.c | 7 +++++-- > drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c | 12 +++++++++--- i40e and mlx5 patches you may or may not want to post separately so that Intel and Mellanox can take them via their trees. > drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c | 25 ++++++++++++------------- > drivers/net/ethernet/qlogic/qed/qed_dev.c | 11 ++++++----- > drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 26 ++++++++++++-------------- > drivers/net/ethernet/qlogic/qed/qed_spq.c | 6 +++--- > drivers/net/ethernet/qlogic/qede/qede_filter.c | 11 +++++++---- > drivers/net/ethernet/qlogic/qede/qede_rdma.c | 11 +++++------ > drivers/net/ethernet/sfc/rx_common.c | 6 ++++-- > drivers/net/ethernet/ti/netcp_core.c | 24 ++++++++++++++++-------- > drivers/net/ethernet/toshiba/ps3_gelic_wireless.c | 30 +++++++++++++++--------------- > drivers/net/ipvlan/ipvlan_main.c | 7 +++++-- > drivers/net/rionet.c | 14 +++++++------- > drivers/net/team/team.c | 20 +++++++++++++------- yup, that's all net-next > drivers/net/wireless/ath/ath10k/mac.c | 19 ++++++++++--------- > drivers/net/wireless/ath/ath11k/dp_rx.c | 15 +++++++-------- > drivers/net/wireless/ath/ath11k/wmi.c | 11 +++++------ > drivers/net/wireless/ath/ath6kl/htc_mbox.c | 2 +- > drivers/net/wireless/intel/ipw2x00/libipw_rx.c | 14 ++++++++------ Wireless goes to Kalle and Johannes. > drivers/rapidio/devices/rio_mport_cdev.c | 42 ++++++++++++++++++++---------------------- > drivers/rapidio/devices/tsi721.c | 13 ++++++------- > drivers/rapidio/rio.c | 14 +++++++------- > drivers/rapidio/rio_cm.c | 81 ++++++++++++++++++++++++++++++++++++ That's not networking. > net/9p/trans_virtio.c | 15 +++++++-------- > net/9p/trans_xen.c | 10 ++++++---- Also not really networking, those go thru other people's trees. > net/core/devlink.c | 22 +++++++++++++++------- > net/core/gro.c | 12 ++++++++---- > net/dsa/dsa.c | 11 +++++------ yup, net-next > net/ieee802154/core.c | 7 +++++-- individual posting for Stefan to take via his tree > net/ipv4/udp_tunnel_nic.c | 10 ++++++---- yup > net/mac80211/offchannel.c | 28 ++++++++++++++-------------- > net/mac80211/util.c | 7 +++++-- This is wireless, so Johannes & Kalle. > net/sched/sch_cbs.c | 11 +++++------ > net/sched/sch_taprio.c | 11 +++++------ > net/smc/smc_ism.c | 14 +++++++------- > net/tipc/group.c | 12 ++++++++---- > net/tipc/monitor.c | 21 ++++++++++++++------- > net/tipc/name_table.c | 11 +++++++---- > net/tipc/socket.c | 11 +++++++---- yup > net/wireless/core.c | 7 +++++-- wireless > net/xfrm/xfrm_ipcomp.c | 11 +++++++---- IPsec, so Steffen and Herbert, separate posting. > 51 files changed, 452 insertions(+), 364 deletions(-) So 21-ish patches for net-next if you group changes for a same driver / project into one patch. Two series 10+ patches each? > Please let me know if I should split it up or if there are certain files that might not fit. > Otherwise I'll post them beginning of next week.
diff --git a/net/sched/sch_cbs.c b/net/sched/sch_cbs.c index 459cc240eda9..4ea93a5d46cf 100644 --- a/net/sched/sch_cbs.c +++ b/net/sched/sch_cbs.c @@ -333,9 +333,8 @@ static int cbs_dev_notifier(struct notifier_block *nb, unsigned long event, void *ptr) { struct net_device *dev = netdev_notifier_info_to_dev(ptr); - struct cbs_sched_data *q; + struct cbs_sched_data *q = NULL, *iter; struct net_device *qdev; - bool found = false; ASSERT_RTNL(); @@ -343,16 +342,16 @@ static int cbs_dev_notifier(struct notifier_block *nb, unsigned long event, return NOTIFY_DONE; spin_lock(&cbs_list_lock); - list_for_each_entry(q, &cbs_list, cbs_list) { - qdev = qdisc_dev(q->qdisc); + list_for_each_entry(iter, &cbs_list, cbs_list) { + qdev = qdisc_dev(iter->qdisc); if (qdev == dev) { - found = true; + q = iter; break; } } spin_unlock(&cbs_list_lock); - if (found) + if (q) cbs_set_port_rate(dev, q); return NOTIFY_DONE; diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c index 377f896bdedc..9403ae4bf107 100644 --- a/net/sched/sch_taprio.c +++ b/net/sched/sch_taprio.c @@ -1096,9 +1096,8 @@ static int taprio_dev_notifier(struct notifier_block *nb, unsigned long event, void *ptr) { struct net_device *dev = netdev_notifier_info_to_dev(ptr); + struct taprio_sched *q = NULL, *iter; struct net_device *qdev; - struct taprio_sched *q; - bool found = false; ASSERT_RTNL(); @@ -1106,16 +1105,16 @@ static int taprio_dev_notifier(struct notifier_block *nb, unsigned long event, return NOTIFY_DONE; spin_lock(&taprio_list_lock); - list_for_each_entry(q, &taprio_list, taprio_list) { - qdev = qdisc_dev(q->root); + list_for_each_entry(iter, &taprio_list, taprio_list) { + qdev = qdisc_dev(iter->root); if (qdev == dev) { - found = true; + q = iter; break; } } spin_unlock(&taprio_list_lock); - if (found) + if (q) taprio_set_picos_per_byte(dev, q); return NOTIFY_DONE;
To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the list iterator variable after the loop body. To *never* use the list iterator variable after the loop it was concluded to use a separate iterator variable instead of a found boolean [1]. This removes the need to use a found variable and simply checking if the variable was set, can determine if the break/goto was hit. Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> --- net/sched/sch_cbs.c | 11 +++++------ net/sched/sch_taprio.c | 11 +++++------ 2 files changed, 10 insertions(+), 12 deletions(-) base-commit: f443e374ae131c168a065ea1748feac6b2e76613