| Message ID | 20230426165835.443259-1-kory.maincent@bootlin.com (mailing list archive) |
|---|---|
| State | RFC |
| Delegated to: | Netdev Maintainers |
| Headers | show |
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.
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!
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!
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?
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?
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.
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?
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? >
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/
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!
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; }
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(-)