* [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set @ 2023-04-23 3:24 Maxim Georgiev 2023-04-26 16:58 ` Köry Maincent 0 siblings, 1 reply; 12+ messages in thread From: Maxim Georgiev @ 2023-04-23 3:24 UTC (permalink / raw) To: glipus, kory.maincent Cc: kuba, netdev, maxime.chevallier, vladimir.oltean, vadim.fedorenko, richardcochran, gerhard This stack of patches introduces a couple of new NDO methods, ndo_hwtstamp_get and ndo_hwtstamp_set. These new methods can be implemented by NIC drivers to allow setting and querying HW timestamp settings. Drivers implementing these methods will not need to handle SIOCGHWTSTAMP/SIOCSHWTSTAMP IOCTLs. The new NDO methods will handle copying request parameters between user address space and kernel space. Maxim Georgiev (5): Add NDOs for hardware timestamp get/set Add ifreq pointer field to kernel_hwtstamp_config structure Add ndo_hwtstamp_get/set support to vlan/maxvlan code path Add ndo_hwtstamp_get/set support to bond driver Implement ndo_hwtstamp_get/set methods in netdevsim driver drivers/net/bonding/bond_main.c | 106 +++++++++++++++++----------- drivers/net/macvlan.c | 34 ++++----- drivers/net/netdevsim/ethtool.c | 11 +++ drivers/net/netdevsim/netdev.c | 24 +++++++ drivers/net/netdevsim/netdevsim.h | 1 + include/linux/net_tstamp.h | 15 ++++ include/linux/netdevice.h | 22 ++++++ net/8021q/vlan_dev.c | 25 +++++-- net/core/dev_ioctl.c | 110 +++++++++++++++++++++++++++++- 9 files changed, 279 insertions(+), 69 deletions(-) -- 2.39.2 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set 2023-04-23 3:24 [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set Maxim Georgiev @ 2023-04-26 16:58 ` Köry Maincent 2023-04-27 4:00 ` Max Georgiev 0 siblings, 1 reply; 12+ messages in thread From: Köry Maincent @ 2023-04-26 16:58 UTC (permalink / raw) To: glipus Cc: kory.maincent, kuba, netdev, maxime.chevallier, vladimir.oltean, vadim.fedorenko, richardcochran, gerhard, thomas.petazzoni From: Kory Maincent <kory.maincent@bootlin.com> You patch series work on my side with the macb MAC controller and this patch. I don't know if you are waiting for more reviews but it seems good enough to drop the RFC tag. --- drivers/net/ethernet/cadence/macb.h | 10 ++++++-- drivers/net/ethernet/cadence/macb_main.c | 15 ++++-------- drivers/net/ethernet/cadence/macb_ptp.c | 30 ++++++++++++++---------- 3 files changed, 29 insertions(+), 26 deletions(-) diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h index cfbdd0022764..bc73b080093e 100644 --- a/drivers/net/ethernet/cadence/macb.h +++ b/drivers/net/ethernet/cadence/macb.h @@ -1350,8 +1350,14 @@ static inline void gem_ptp_do_rxstamp(struct macb *bp, struct sk_buff *skb, stru gem_ptp_rxstamp(bp, skb, desc); } -int gem_get_hwtst(struct net_device *dev, struct ifreq *rq); -int gem_set_hwtst(struct net_device *dev, struct ifreq *ifr, int cmd); + +int gem_get_hwtst(struct net_device *dev, + struct kernel_hwtstamp_config *kernel_config, + struct netlink_ext_ack *extack); +int gem_set_hwtst(struct net_device *dev, + struct kernel_hwtstamp_config *kernel_config, + struct netlink_ext_ack *extack); + #else static inline void gem_ptp_init(struct net_device *ndev) { } static inline void gem_ptp_remove(struct net_device *ndev) { } diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c index 45f63df5bdc4..c1d65be88835 100644 --- a/drivers/net/ethernet/cadence/macb_main.c +++ b/drivers/net/ethernet/cadence/macb_main.c @@ -3402,8 +3402,6 @@ static struct macb_ptp_info gem_ptp_info = { .get_ptp_max_adj = gem_get_ptp_max_adj, .get_tsu_rate = gem_get_tsu_rate, .get_ts_info = gem_get_ts_info, - .get_hwtst = gem_get_hwtst, - .set_hwtst = gem_set_hwtst, }; #endif @@ -3764,15 +3762,6 @@ static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) if (!netif_running(dev)) return -EINVAL; - if (!phy_has_hwtstamp(dev->phydev) && bp->ptp_info) { - switch (cmd) { - case SIOCSHWTSTAMP: - return bp->ptp_info->set_hwtst(dev, rq, cmd); - case SIOCGHWTSTAMP: - return bp->ptp_info->get_hwtst(dev, rq); - } - } - return phylink_mii_ioctl(bp->phylink, rq, cmd); } @@ -3875,6 +3864,10 @@ static const struct net_device_ops macb_netdev_ops = { #endif .ndo_set_features = macb_set_features, .ndo_features_check = macb_features_check, +#ifdef CONFIG_MACB_USE_HWSTAMP + .ndo_hwtstamp_get = gem_get_hwtst, + .ndo_hwtstamp_set = gem_set_hwtst, +#endif }; /* Configure peripheral capabilities according to device tree diff --git a/drivers/net/ethernet/cadence/macb_ptp.c b/drivers/net/ethernet/cadence/macb_ptp.c index 51d26fa190d7..eddacc5df435 100644 --- a/drivers/net/ethernet/cadence/macb_ptp.c +++ b/drivers/net/ethernet/cadence/macb_ptp.c @@ -374,19 +374,22 @@ static int gem_ptp_set_ts_mode(struct macb *bp, return 0; } -int gem_get_hwtst(struct net_device *dev, struct ifreq *rq) +int gem_get_hwtst(struct net_device *dev, + struct kernel_hwtstamp_config *kernel_config, + struct netlink_ext_ack *extack) { struct hwtstamp_config *tstamp_config; struct macb *bp = netdev_priv(dev); + if (phy_has_hwtstamp(dev->phydev)) + return phylink_mii_ioctl(bp->phylink, kernel_config->ifr, SIOCGHWTSTAMP); + tstamp_config = &bp->tstamp_config; if ((bp->hw_dma_cap & HW_DMA_CAP_PTP) == 0) return -EOPNOTSUPP; - if (copy_to_user(rq->ifr_data, tstamp_config, sizeof(*tstamp_config))) - return -EFAULT; - else - return 0; + hwtstamp_config_to_kernel(kernel_config, tstamp_config); + return 0; } static void gem_ptp_set_one_step_sync(struct macb *bp, u8 enable) @@ -401,7 +404,9 @@ static void gem_ptp_set_one_step_sync(struct macb *bp, u8 enable) macb_writel(bp, NCR, reg_val & ~MACB_BIT(OSSMODE)); } -int gem_set_hwtst(struct net_device *dev, struct ifreq *ifr, int cmd) +int gem_set_hwtst(struct net_device *dev, + struct kernel_hwtstamp_config *kernel_config, + struct netlink_ext_ack *extack) { enum macb_bd_control tx_bd_control = TSTAMP_DISABLED; enum macb_bd_control rx_bd_control = TSTAMP_DISABLED; @@ -409,13 +414,14 @@ int gem_set_hwtst(struct net_device *dev, struct ifreq *ifr, int cmd) struct macb *bp = netdev_priv(dev); u32 regval; + if (phy_has_hwtstamp(dev->phydev)) + return phylink_mii_ioctl(bp->phylink, kernel_config->ifr, SIOCSHWTSTAMP); + tstamp_config = &bp->tstamp_config; if ((bp->hw_dma_cap & HW_DMA_CAP_PTP) == 0) return -EOPNOTSUPP; - if (copy_from_user(tstamp_config, ifr->ifr_data, - sizeof(*tstamp_config))) - return -EFAULT; + hwtstamp_config_from_kernel(tstamp_config, kernel_config); switch (tstamp_config->tx_type) { case HWTSTAMP_TX_OFF: @@ -466,9 +472,7 @@ int gem_set_hwtst(struct net_device *dev, struct ifreq *ifr, int cmd) if (gem_ptp_set_ts_mode(bp, tx_bd_control, rx_bd_control) != 0) return -ERANGE; - if (copy_to_user(ifr->ifr_data, tstamp_config, sizeof(*tstamp_config))) - return -EFAULT; - else - return 0; + hwtstamp_config_to_kernel(kernel_config, tstamp_config); + return 0; } -- 2.25.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set 2023-04-26 16:58 ` Köry Maincent @ 2023-04-27 4:00 ` Max Georgiev 2023-04-27 8:43 ` Köry Maincent 0 siblings, 1 reply; 12+ messages in thread From: Max Georgiev @ 2023-04-27 4:00 UTC (permalink / raw) To: Köry Maincent Cc: kuba, netdev, maxime.chevallier, vladimir.oltean, vadim.fedorenko, richardcochran, gerhard, thomas.petazzoni On Wed, Apr 26, 2023 at 10:58 AM Köry Maincent <kory.maincent@bootlin.com> wrote: > > From: Kory Maincent <kory.maincent@bootlin.com> > > You patch series work on my side with the macb MAC controller and this > patch. > I don't know if you are waiting for more reviews but it seems good enough > to drop the RFC tag. > > --- > > drivers/net/ethernet/cadence/macb.h | 10 ++++++-- > drivers/net/ethernet/cadence/macb_main.c | 15 ++++-------- > drivers/net/ethernet/cadence/macb_ptp.c | 30 ++++++++++++++---------- > 3 files changed, 29 insertions(+), 26 deletions(-) > > diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h > index cfbdd0022764..bc73b080093e 100644 > --- a/drivers/net/ethernet/cadence/macb.h > +++ b/drivers/net/ethernet/cadence/macb.h > @@ -1350,8 +1350,14 @@ static inline void gem_ptp_do_rxstamp(struct macb *bp, struct sk_buff *skb, stru > > gem_ptp_rxstamp(bp, skb, desc); > } > -int gem_get_hwtst(struct net_device *dev, struct ifreq *rq); > -int gem_set_hwtst(struct net_device *dev, struct ifreq *ifr, int cmd); > + > +int gem_get_hwtst(struct net_device *dev, > + struct kernel_hwtstamp_config *kernel_config, > + struct netlink_ext_ack *extack); > +int gem_set_hwtst(struct net_device *dev, > + struct kernel_hwtstamp_config *kernel_config, > + struct netlink_ext_ack *extack); > + > #else > static inline void gem_ptp_init(struct net_device *ndev) { } > static inline void gem_ptp_remove(struct net_device *ndev) { } > diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c > index 45f63df5bdc4..c1d65be88835 100644 > --- a/drivers/net/ethernet/cadence/macb_main.c > +++ b/drivers/net/ethernet/cadence/macb_main.c > @@ -3402,8 +3402,6 @@ static struct macb_ptp_info gem_ptp_info = { > .get_ptp_max_adj = gem_get_ptp_max_adj, > .get_tsu_rate = gem_get_tsu_rate, > .get_ts_info = gem_get_ts_info, > - .get_hwtst = gem_get_hwtst, > - .set_hwtst = gem_set_hwtst, > }; > #endif > > @@ -3764,15 +3762,6 @@ static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) > if (!netif_running(dev)) > return -EINVAL; > > - if (!phy_has_hwtstamp(dev->phydev) && bp->ptp_info) { > - switch (cmd) { > - case SIOCSHWTSTAMP: > - return bp->ptp_info->set_hwtst(dev, rq, cmd); > - case SIOCGHWTSTAMP: > - return bp->ptp_info->get_hwtst(dev, rq); > - } > - } > - > return phylink_mii_ioctl(bp->phylink, rq, cmd); > } > > @@ -3875,6 +3864,10 @@ static const struct net_device_ops macb_netdev_ops = { > #endif > .ndo_set_features = macb_set_features, > .ndo_features_check = macb_features_check, > +#ifdef CONFIG_MACB_USE_HWSTAMP > + .ndo_hwtstamp_get = gem_get_hwtst, > + .ndo_hwtstamp_set = gem_set_hwtst, > +#endif > }; > > /* Configure peripheral capabilities according to device tree > diff --git a/drivers/net/ethernet/cadence/macb_ptp.c b/drivers/net/ethernet/cadence/macb_ptp.c > index 51d26fa190d7..eddacc5df435 100644 > --- a/drivers/net/ethernet/cadence/macb_ptp.c > +++ b/drivers/net/ethernet/cadence/macb_ptp.c > @@ -374,19 +374,22 @@ static int gem_ptp_set_ts_mode(struct macb *bp, > return 0; > } > > -int gem_get_hwtst(struct net_device *dev, struct ifreq *rq) > +int gem_get_hwtst(struct net_device *dev, > + struct kernel_hwtstamp_config *kernel_config, > + struct netlink_ext_ack *extack) > { > struct hwtstamp_config *tstamp_config; > struct macb *bp = netdev_priv(dev); > > + if (phy_has_hwtstamp(dev->phydev)) > + return phylink_mii_ioctl(bp->phylink, kernel_config->ifr, SIOCGHWTSTAMP); > + > tstamp_config = &bp->tstamp_config; > if ((bp->hw_dma_cap & HW_DMA_CAP_PTP) == 0) > return -EOPNOTSUPP; > > - if (copy_to_user(rq->ifr_data, tstamp_config, sizeof(*tstamp_config))) > - return -EFAULT; > - else > - return 0; > + hwtstamp_config_to_kernel(kernel_config, tstamp_config); > + return 0; > } > > static void gem_ptp_set_one_step_sync(struct macb *bp, u8 enable) > @@ -401,7 +404,9 @@ static void gem_ptp_set_one_step_sync(struct macb *bp, u8 enable) > macb_writel(bp, NCR, reg_val & ~MACB_BIT(OSSMODE)); > } > > -int gem_set_hwtst(struct net_device *dev, struct ifreq *ifr, int cmd) > +int gem_set_hwtst(struct net_device *dev, > + struct kernel_hwtstamp_config *kernel_config, > + struct netlink_ext_ack *extack) > { > enum macb_bd_control tx_bd_control = TSTAMP_DISABLED; > enum macb_bd_control rx_bd_control = TSTAMP_DISABLED; > @@ -409,13 +414,14 @@ int gem_set_hwtst(struct net_device *dev, struct ifreq *ifr, int cmd) > struct macb *bp = netdev_priv(dev); > u32 regval; > > + if (phy_has_hwtstamp(dev->phydev)) > + return phylink_mii_ioctl(bp->phylink, kernel_config->ifr, SIOCSHWTSTAMP); > + > tstamp_config = &bp->tstamp_config; > if ((bp->hw_dma_cap & HW_DMA_CAP_PTP) == 0) > return -EOPNOTSUPP; > > - if (copy_from_user(tstamp_config, ifr->ifr_data, > - sizeof(*tstamp_config))) > - return -EFAULT; > + hwtstamp_config_from_kernel(tstamp_config, kernel_config); > > switch (tstamp_config->tx_type) { > case HWTSTAMP_TX_OFF: > @@ -466,9 +472,7 @@ int gem_set_hwtst(struct net_device *dev, struct ifreq *ifr, int cmd) > if (gem_ptp_set_ts_mode(bp, tx_bd_control, rx_bd_control) != 0) > return -ERANGE; > > - if (copy_to_user(ifr->ifr_data, tstamp_config, sizeof(*tstamp_config))) > - return -EFAULT; > - else > - return 0; > + hwtstamp_config_to_kernel(kernel_config, tstamp_config); > + return 0; > } > > -- > 2.25.1 > Thank you for giving it a try! I'll drop the RFC tag starting from the next iteration. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set 2023-04-27 4:00 ` Max Georgiev @ 2023-04-27 8:43 ` Köry Maincent 2023-04-28 4:57 ` Max Georgiev 0 siblings, 1 reply; 12+ messages in thread From: Köry Maincent @ 2023-04-27 8:43 UTC (permalink / raw) To: Max Georgiev Cc: kuba, netdev, maxime.chevallier, vladimir.oltean, vadim.fedorenko, richardcochran, gerhard, thomas.petazzoni On Wed, 26 Apr 2023 22:00:43 -0600 Max Georgiev <glipus@gmail.com> wrote: > > Thank you for giving it a try! > I'll drop the RFC tag starting from the next iteration. Sorry I didn't know the net-next submission rules. In fact keep the RFC tag until net-next open again. http://vger.kernel.org/~davem/net-next.html Your patch series don't appear in the cover letter thread: https://lore.kernel.org/all/20230423032437.285014-1-glipus@gmail.com/ I don't know if it comes from your e-mail or just some issue from lore but could you check it? Please add "net:" prefix to your patches commit title when changing the net core, "macvlan:" prefix for macvlan driver change, etc ... Also I see you forgot "net-next" to the subject prefix in this iteration please don't in next one. Thanks for your work! ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set 2023-04-27 8:43 ` Köry Maincent @ 2023-04-28 4:57 ` Max Georgiev 2023-04-28 8:11 ` Köry Maincent 0 siblings, 1 reply; 12+ messages in thread From: Max Georgiev @ 2023-04-28 4:57 UTC (permalink / raw) To: Köry Maincent Cc: kuba, netdev, maxime.chevallier, vladimir.oltean, vadim.fedorenko, richardcochran, gerhard, thomas.petazzoni Sorry, I'm still learning the kernel patch communication rules. Thank you for guiding me here. On Thu, Apr 27, 2023 at 2:43 AM Köry Maincent <kory.maincent@bootlin.com> wrote: > > On Wed, 26 Apr 2023 22:00:43 -0600 > Max Georgiev <glipus@gmail.com> wrote: > > > > > Thank you for giving it a try! > > I'll drop the RFC tag starting from the next iteration. > > Sorry I didn't know the net-next submission rules. In fact keep the RFC tag > until net-next open again. > http://vger.kernel.org/~davem/net-next.html > > Your patch series don't appear in the cover letter thread: > https://lore.kernel.org/all/20230423032437.285014-1-glipus@gmail.com/ > I don't know if it comes from your e-mail or just some issue from lore but could > you check it? Could you please elaborate what's missing in the cover letter? Should the cover letter contain the latest version of the patch stack (v4, then v5, etc.) and some description of the differences between the patch versions? Let me look up some written guidance on this. > > Please add "net:" prefix to your patches commit title when changing the net > core, "macvlan:" prefix for macvlan driver change, etc ... Will certainly add tem. > > Also I see you forgot "net-next" to the subject prefix in this iteration please > don't in next one. My bad, will add it back. > > Thanks for your work! ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set 2023-04-28 4:57 ` Max Georgiev @ 2023-04-28 8:11 ` Köry Maincent 2023-04-28 14:14 ` Max Georgiev 0 siblings, 1 reply; 12+ messages in thread From: Köry Maincent @ 2023-04-28 8:11 UTC (permalink / raw) To: Max Georgiev Cc: kuba, netdev, maxime.chevallier, vladimir.oltean, vadim.fedorenko, richardcochran, gerhard, thomas.petazzoni On Thu, 27 Apr 2023 22:57:27 -0600 Max Georgiev <glipus@gmail.com> wrote: > Sorry, I'm still learning the kernel patch communication rules. > Thank you for guiding me here. Also, each Linux merging subtree can have its own rules. I also, was not aware of net special merging rules: https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html > On Thu, Apr 27, 2023 at 2:43 AM Köry Maincent <kory.maincent@bootlin.com> > wrote: > > > > On Wed, 26 Apr 2023 22:00:43 -0600 > > Max Georgiev <glipus@gmail.com> wrote: > > > > > > > > Thank you for giving it a try! > > > I'll drop the RFC tag starting from the next iteration. > > > > Sorry I didn't know the net-next submission rules. In fact keep the RFC tag > > until net-next open again. > > http://vger.kernel.org/~davem/net-next.html > > > > Your patch series don't appear in the cover letter thread: > > https://lore.kernel.org/all/20230423032437.285014-1-glipus@gmail.com/ > > I don't know if it comes from your e-mail or just some issue from lore but > > could you check it? > > Could you please elaborate what's missing in the cover letter? > Should the cover letter contain the latest version of the patch > stack (v4, then v5, etc.) and some description of the differences > between the patch versions? > Let me look up some written guidance on this. I don't know how you send your patch series but when you look on your e-mail thread the patches are not present: https://lore.kernel.org/all/20230423032437.285014-1-glipus@gmail.com/ It is way easier to find your patches when you have all the patches of the series in the e-mail thread. Here for example they are in the thread: https://lore.kernel.org/all/20230406173308.401924-1-kory.maincent@bootlin.com/ Do you use git send-email? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set 2023-04-28 8:11 ` Köry Maincent @ 2023-04-28 14:14 ` Max Georgiev 2023-04-28 14:34 ` Köry Maincent 2023-04-29 19:44 ` Vadim Fedorenko 0 siblings, 2 replies; 12+ messages in thread From: Max Georgiev @ 2023-04-28 14:14 UTC (permalink / raw) To: Köry Maincent Cc: kuba, netdev, maxime.chevallier, vladimir.oltean, vadim.fedorenko, richardcochran, gerhard, thomas.petazzoni On Fri, Apr 28, 2023 at 2:11 AM Köry Maincent <kory.maincent@bootlin.com> wrote: > > On Thu, 27 Apr 2023 22:57:27 -0600 > Max Georgiev <glipus@gmail.com> wrote: > > > Sorry, I'm still learning the kernel patch communication rules. > > Thank you for guiding me here. > > Also, each Linux merging subtree can have its own rules. > I also, was not aware of net special merging rules: > https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html > > > > On Thu, Apr 27, 2023 at 2:43 AM Köry Maincent <kory.maincent@bootlin.com> > > wrote: > > > > > > On Wed, 26 Apr 2023 22:00:43 -0600 > > > Max Georgiev <glipus@gmail.com> wrote: > > > > > > > > > > > Thank you for giving it a try! > > > > I'll drop the RFC tag starting from the next iteration. > > > > > > Sorry I didn't know the net-next submission rules. In fact keep the RFC tag > > > until net-next open again. > > > http://vger.kernel.org/~davem/net-next.html > > > > > > Your patch series don't appear in the cover letter thread: > > > https://lore.kernel.org/all/20230423032437.285014-1-glipus@gmail.com/ > > > I don't know if it comes from your e-mail or just some issue from lore but > > > could you check it? > > > > Could you please elaborate what's missing in the cover letter? > > Should the cover letter contain the latest version of the patch > > stack (v4, then v5, etc.) and some description of the differences > > between the patch versions? > > Let me look up some written guidance on this. > > I don't know how you send your patch series but when you look on your e-mail > thread the patches are not present: > https://lore.kernel.org/all/20230423032437.285014-1-glipus@gmail.com/ > > It is way easier to find your patches when you have all the patches of the > series in the e-mail thread. > Aha, I see the problem now. I guess it has something to do with "--in-reply-to" git send-email optio or similar options. > Here for example they are in the thread: > https://lore.kernel.org/all/20230406173308.401924-1-kory.maincent@bootlin.com/ > > Do you use git send-email? Yes, I use "git format-patch" to generate individual patch files for every patch in the stack, and then I use "git send-email" to send out these patches on-by-one. Is there a recommended way to send out stacks of patches? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set 2023-04-28 14:14 ` Max Georgiev @ 2023-04-28 14:34 ` Köry Maincent 2023-04-29 19:44 ` Vadim Fedorenko 1 sibling, 0 replies; 12+ messages in thread From: Köry Maincent @ 2023-04-28 14:34 UTC (permalink / raw) To: Max Georgiev Cc: kuba, netdev, maxime.chevallier, vladimir.oltean, vadim.fedorenko, richardcochran, gerhard, thomas.petazzoni On Fri, 28 Apr 2023 08:14:57 -0600 Max Georgiev <glipus@gmail.com> wrote: > > Do you use git send-email? > > Yes, I use "git format-patch" to generate individual patch files for > every patch in the > stack, and then I use "git send-email" to send out these patches on-by-one. I think here is the issue. Send your patch series in one "git send-email" go not one-by-one. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set 2023-04-28 14:14 ` Max Georgiev 2023-04-28 14:34 ` Köry Maincent @ 2023-04-29 19:44 ` Vadim Fedorenko 2023-05-02 4:35 ` Max Georgiev 1 sibling, 1 reply; 12+ messages in thread From: Vadim Fedorenko @ 2023-04-29 19:44 UTC (permalink / raw) To: Max Georgiev Cc: kuba, netdev, maxime.chevallier, vladimir.oltean, richardcochran, gerhard, thomas.petazzoni, Köry Maincent On 28.04.2023 15:14, Max Georgiev wrote: > On Fri, Apr 28, 2023 at 2:11 AM Köry Maincent <kory.maincent@bootlin.com> wrote: >> >> On Thu, 27 Apr 2023 22:57:27 -0600 >> Max Georgiev <glipus@gmail.com> wrote: >> >>> Sorry, I'm still learning the kernel patch communication rules. >>> Thank you for guiding me here. >> >> Also, each Linux merging subtree can have its own rules. >> I also, was not aware of net special merging rules: >> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html >> >> >>> On Thu, Apr 27, 2023 at 2:43 AM Köry Maincent <kory.maincent@bootlin.com> >>> wrote: >>>> >>>> On Wed, 26 Apr 2023 22:00:43 -0600 >>>> Max Georgiev <glipus@gmail.com> wrote: >>>> >>>>> >>>>> Thank you for giving it a try! >>>>> I'll drop the RFC tag starting from the next iteration. >>>> >>>> Sorry I didn't know the net-next submission rules. In fact keep the RFC tag >>>> until net-next open again. >>>> http://vger.kernel.org/~davem/net-next.html >>>> >>>> Your patch series don't appear in the cover letter thread: >>>> https://lore.kernel.org/all/20230423032437.285014-1-glipus@gmail.com/ >>>> I don't know if it comes from your e-mail or just some issue from lore but >>>> could you check it? >>> >>> Could you please elaborate what's missing in the cover letter? >>> Should the cover letter contain the latest version of the patch >>> stack (v4, then v5, etc.) and some description of the differences >>> between the patch versions? >>> Let me look up some written guidance on this. >> >> I don't know how you send your patch series but when you look on your e-mail >> thread the patches are not present: >> https://lore.kernel.org/all/20230423032437.285014-1-glipus@gmail.com/ >> >> It is way easier to find your patches when you have all the patches of the >> series in the e-mail thread. >> > > Aha, I see the problem now. I guess it has something to do with "--in-reply-to" > git send-email optio or similar options. > >> Here for example they are in the thread: >> https://lore.kernel.org/all/20230406173308.401924-1-kory.maincent@bootlin.com/ >> >> Do you use git send-email? > > Yes, I use "git format-patch" to generate individual patch files for > every patch in the > stack, and then I use "git send-email" to send out these patches on-by-one. > The problem is, as Köry has mentioned already, in sending patches one-by-one. You can provide a directory with patches to git send-email and it will take all of them at once. You can try it with --dry-run and check that all pacthes have the same In-Reply-To and References headers. > Is there a recommended way to send out stacks of patches? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set 2023-04-29 19:44 ` Vadim Fedorenko @ 2023-05-02 4:35 ` Max Georgiev 2023-05-02 4:44 ` Max Georgiev 0 siblings, 1 reply; 12+ messages in thread From: Max Georgiev @ 2023-05-02 4:35 UTC (permalink / raw) To: Vadim Fedorenko Cc: kuba, netdev, maxime.chevallier, vladimir.oltean, richardcochran, gerhard, thomas.petazzoni, Köry Maincent On Sat, Apr 29, 2023 at 1:45 PM Vadim Fedorenko <vadim.fedorenko@linux.dev> wrote: > > On 28.04.2023 15:14, Max Georgiev wrote: > > On Fri, Apr 28, 2023 at 2:11 AM Köry Maincent <kory.maincent@bootlin.com> wrote: > >> > >> On Thu, 27 Apr 2023 22:57:27 -0600 > >> Max Georgiev <glipus@gmail.com> wrote: > >> > >>> Sorry, I'm still learning the kernel patch communication rules. > >>> Thank you for guiding me here. > >> > >> Also, each Linux merging subtree can have its own rules. > >> I also, was not aware of net special merging rules: > >> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html > >> > >> > >>> On Thu, Apr 27, 2023 at 2:43 AM Köry Maincent <kory.maincent@bootlin.com> > >>> wrote: > >>>> > >>>> On Wed, 26 Apr 2023 22:00:43 -0600 > >>>> Max Georgiev <glipus@gmail.com> wrote: > >>>> > >>>>> > >>>>> Thank you for giving it a try! > >>>>> I'll drop the RFC tag starting from the next iteration. > >>>> > >>>> Sorry I didn't know the net-next submission rules. In fact keep the RFC tag > >>>> until net-next open again. > >>>> http://vger.kernel.org/~davem/net-next.html > >>>> > >>>> Your patch series don't appear in the cover letter thread: > >>>> https://lore.kernel.org/all/20230423032437.285014-1-glipus@gmail.com/ > >>>> I don't know if it comes from your e-mail or just some issue from lore but > >>>> could you check it? > >>> > >>> Could you please elaborate what's missing in the cover letter? > >>> Should the cover letter contain the latest version of the patch > >>> stack (v4, then v5, etc.) and some description of the differences > >>> between the patch versions? > >>> Let me look up some written guidance on this. > >> > >> I don't know how you send your patch series but when you look on your e-mail > >> thread the patches are not present: > >> https://lore.kernel.org/all/20230423032437.285014-1-glipus@gmail.com/ > >> > >> It is way easier to find your patches when you have all the patches of the > >> series in the e-mail thread. > >> > > > > Aha, I see the problem now. I guess it has something to do with "--in-reply-to" > > git send-email optio or similar options. > > > >> Here for example they are in the thread: > >> https://lore.kernel.org/all/20230406173308.401924-1-kory.maincent@bootlin.com/ > >> > >> Do you use git send-email? > > > > Yes, I use "git format-patch" to generate individual patch files for > > every patch in the > > stack, and then I use "git send-email" to send out these patches on-by-one. > > > > The problem is, as Köry has mentioned already, in sending patches one-by-one. > You can provide a directory with patches to git send-email and it will take all > of them at once. You can try it with --dry-run and check that all pacthes have > the same In-Reply-To and References headers. So the best practice for sending patch stacks is to run "git send-email ..." against a folder containing the freshly generated patch files! Thank you for the guidance! > > > Is there a recommended way to send out stacks of patches? > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set 2023-05-02 4:35 ` Max Georgiev @ 2023-05-02 4:44 ` Max Georgiev 2023-05-02 9:13 ` Köry Maincent 0 siblings, 1 reply; 12+ messages in thread From: Max Georgiev @ 2023-05-02 4:44 UTC (permalink / raw) To: Vadim Fedorenko Cc: kuba, netdev, maxime.chevallier, vladimir.oltean, richardcochran, gerhard, thomas.petazzoni, Köry Maincent On Mon, May 1, 2023 at 10:35 PM Max Georgiev <glipus@gmail.com> wrote: > > On Sat, Apr 29, 2023 at 1:45 PM Vadim Fedorenko > <vadim.fedorenko@linux.dev> wrote: > > > > On 28.04.2023 15:14, Max Georgiev wrote: > > > On Fri, Apr 28, 2023 at 2:11 AM Köry Maincent <kory.maincent@bootlin.com> wrote: > > >> > > >> On Thu, 27 Apr 2023 22:57:27 -0600 > > >> Max Georgiev <glipus@gmail.com> wrote: > > >> > > >>> Sorry, I'm still learning the kernel patch communication rules. > > >>> Thank you for guiding me here. > > >> > > >> Also, each Linux merging subtree can have its own rules. > > >> I also, was not aware of net special merging rules: > > >> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html > > >> > > >> > > >>> On Thu, Apr 27, 2023 at 2:43 AM Köry Maincent <kory.maincent@bootlin.com> > > >>> wrote: > > >>>> > > >>>> On Wed, 26 Apr 2023 22:00:43 -0600 > > >>>> Max Georgiev <glipus@gmail.com> wrote: > > >>>> > > >>>>> > > >>>>> Thank you for giving it a try! > > >>>>> I'll drop the RFC tag starting from the next iteration. > > >>>> > > >>>> Sorry I didn't know the net-next submission rules. In fact keep the RFC tag > > >>>> until net-next open again. > > >>>> http://vger.kernel.org/~davem/net-next.html > > >>>> > > >>>> Your patch series don't appear in the cover letter thread: > > >>>> https://lore.kernel.org/all/20230423032437.285014-1-glipus@gmail.com/ > > >>>> I don't know if it comes from your e-mail or just some issue from lore but > > >>>> could you check it? > > >>> > > >>> Could you please elaborate what's missing in the cover letter? > > >>> Should the cover letter contain the latest version of the patch > > >>> stack (v4, then v5, etc.) and some description of the differences > > >>> between the patch versions? > > >>> Let me look up some written guidance on this. > > >> > > >> I don't know how you send your patch series but when you look on your e-mail > > >> thread the patches are not present: > > >> https://lore.kernel.org/all/20230423032437.285014-1-glipus@gmail.com/ > > >> > > >> It is way easier to find your patches when you have all the patches of the > > >> series in the e-mail thread. > > >> > > > > > > Aha, I see the problem now. I guess it has something to do with "--in-reply-to" > > > git send-email optio or similar options. > > > > > >> Here for example they are in the thread: > > >> https://lore.kernel.org/all/20230406173308.401924-1-kory.maincent@bootlin.com/ > > >> > > >> Do you use git send-email? > > > > > > Yes, I use "git format-patch" to generate individual patch files for > > > every patch in the > > > stack, and then I use "git send-email" to send out these patches on-by-one. > > > > > > > The problem is, as Köry has mentioned already, in sending patches one-by-one. > > You can provide a directory with patches to git send-email and it will take all > > of them at once. You can try it with --dry-run and check that all pacthes have > > the same In-Reply-To and References headers. > > So the best practice for sending patch stacks is to run "git > send-email ..." against > a folder containing the freshly generated patch files! > Thank you for the guidance! > > > > > > Is there a recommended way to send out stacks of patches? > > Is it better this time? https://lore.kernel.org/netdev/20230502043150.17097-1-glipus@gmail.com/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set 2023-05-02 4:44 ` Max Georgiev @ 2023-05-02 9:13 ` Köry Maincent 0 siblings, 0 replies; 12+ messages in thread From: Köry Maincent @ 2023-05-02 9:13 UTC (permalink / raw) To: Max Georgiev Cc: Vadim Fedorenko, kuba, netdev, maxime.chevallier, vladimir.oltean, richardcochran, gerhard, thomas.petazzoni On Mon, 1 May 2023 22:44:22 -0600 Max Georgiev <glipus@gmail.com> wrote: > Is it better this time? > https://lore.kernel.org/netdev/20230502043150.17097-1-glipus@gmail.com/ Yes it is, thanks! ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-05-02 9:13 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-04-23 3:24 [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set Maxim Georgiev 2023-04-26 16:58 ` Köry Maincent 2023-04-27 4:00 ` Max Georgiev 2023-04-27 8:43 ` Köry Maincent 2023-04-28 4:57 ` Max Georgiev 2023-04-28 8:11 ` Köry Maincent 2023-04-28 14:14 ` Max Georgiev 2023-04-28 14:34 ` Köry Maincent 2023-04-29 19:44 ` Vadim Fedorenko 2023-05-02 4:35 ` Max Georgiev 2023-05-02 4:44 ` Max Georgiev 2023-05-02 9:13 ` Köry Maincent
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).