[RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set

[RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set

[Maxim Georgiev]

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

[RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set

[Köry Maincent]

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

Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set

[Max Georgiev]

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.

Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set

[Köry Maincent]

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!

Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set

[Max Georgiev]

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!

Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set

[Köry Maincent]

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?

Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set

[Max Georgiev]

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?

Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set

[Köry Maincent]

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.

Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set

[Vadim Fedorenko]

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?

Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set

[Max Georgiev]

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?
>

Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set

[Max Georgiev]

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/

Re: [RFC PATCH v4 0/5] New NDO methods ndo_hwtstamp_get/set

[Köry Maincent]

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!