From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "Köry Maincent" <kory.maincent@bootlin.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-omap@vger.kernel.org, "Michael Walle" <michael@walle.cc>,
"Richard Cochran" <richardcochran@gmail.com>,
thomas.petazzoni@bootlin.com,
"Jay Vosburgh" <j.vosburgh@gmail.com>,
"Veaceslav Falico" <vfalico@gmail.com>,
"Andy Gospodarek" <andy@greyhouse.net>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Joakim Zhang" <qiangqing.zhang@nxp.com>,
"Vladimir Oltean" <vladimir.oltean@nxp.com>,
"Claudiu Manoil" <claudiu.manoil@nxp.com>,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
UNGLinuxDriver@microchip.com,
"Grygorii Strashko" <grygorii.strashko@ti.com>,
"Heiner Kallweit" <hkallweit1@gmail.com>,
"Minghao Chi" <chi.minghao@zte.com.cn>,
"Jie Wang" <wangjie125@huawei.com>,
"Guangbin Huang" <huangguangbin2@huawei.com>,
"Wolfram Sang" <wsa+renesas@sang-engineering.com>,
"Wang Yufen" <wangyufen@huawei.com>,
"Alexandru Tachici" <alexandru.tachici@analog.com>,
"Oleksij Rempel" <linux@rempel-privat.de>
Subject: Re: [PATCH v2 3/4] net: Let the active time stamping layer be selectable.
Date: Sat, 4 Mar 2023 16:16:31 +0000 [thread overview]
Message-ID: <ZANu37JHCKwsiCTT@shell.armlinux.org.uk> (raw)
In-Reply-To: <011d63c3-e3ff-4b67-8ab7-d39f541c7b31@lunn.ch>
On Sat, Mar 04, 2023 at 04:43:47PM +0100, Andrew Lunn wrote:
> On Fri, Mar 03, 2023 at 05:42:40PM +0100, Köry Maincent wrote:
> > From: Richard Cochran <richardcochran@gmail.com>
> >
> > Make the sysfs knob writable, and add checks in the ioctl and time
> > stamping paths to respect the currently selected time stamping layer.
>
> Although it probably works, i think the ioctl code is ugly.
>
> I think it would be better to pull the IOCTL code into the PTP object
> interface. Add an ioctl member to struct ptp_clock_info. The PTP core
> can then directly call into the PTP object.
Putting it into ptp_clock_info makes little sense to me, because this
is for the PHC, which is exposed via /dev/ptp*, and that's what the
various methods in that structure are for
The timestamping part is via the netdev, which is a separate entity,
and its that entity which is responsible for identifying which PHC it
is connected to (normally by filling in the phc_index field of
ethtool_ts_info.)
Think of is as:
netdev ---- timestamping ---- PHC
since we can have:
netdev1 ---- timestamping \
netdev2 ---- timestamping -*--- PHC
netdev3 ---- timestamping /
Since the ioctl is to do with requesting what we want the timestamping
layer to be doing with packets, putting it in ptp_clock_info makes
very little sense.
> You now have a rather odd semantic that calling the .ndo_eth_ioctl
> means operate on the MAC PTP. If you look at net_device_ops, i don't
> think any of the other members have this semantic. They all look at
> the netdev as a whole, and ask the netdev to do something, without
> caring what level it operates at. So a PTP ioctl should operate on
> 'the' PTP of the netdev, whichever that might be, MAC or PHY.
Well, what we have today is:
int __ethtool_get_ts_info(struct net_device *dev, struct ethtool_ts_info *info)
{
...
if (phy_has_tsinfo(phydev))
return phy_ts_info(phydev, info);
if (ops->get_ts_info)
return ops->get_ts_info(dev, info);
}
So, one can argue that we already have this "odd" semantic, in that
calling get_ts_info() means to operate on the MAC PTP implementation.
Making the ioctl also do that merely brings it into line with this
existing code!
If we want in general for the netdev to always be called, then we need
to remove the above, but then we need to go through all the networking
drivers working out which need to provide a get_ts_info() and forward
that to phylib. Maybe that's a good thing in the longer run though?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2023-03-04 16:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-03 16:42 [PATCH v2 0/4] Up until now, there was no way to let the user select the layer at which time stamping occurs. The stack assumed that PHY time stamping is always preferred, but some MAC/PHY combinations were buggy Köry Maincent
2023-03-03 16:42 ` [PATCH v2 1/4] net: ethtool: Refactor identical get_ts_info implementations Köry Maincent
2023-03-03 16:42 ` [PATCH v2 2/4] net: Expose available time stamping layers to user space Köry Maincent
2023-03-03 18:13 ` kernel test robot
2023-03-03 23:52 ` Jakub Kicinski
2023-03-03 23:56 ` Willem de Bruijn
2023-03-03 16:42 ` [PATCH v2 3/4] net: Let the active time stamping layer be selectable Köry Maincent
2023-03-03 18:54 ` kernel test robot
2023-03-03 23:59 ` Willem de Bruijn
2023-03-04 15:04 ` Andrew Lunn
2023-03-04 3:06 ` kernel test robot
2023-03-04 15:43 ` Andrew Lunn
2023-03-04 16:16 ` Russell King (Oracle) [this message]
2023-03-04 19:46 ` Andrew Lunn
2023-03-06 17:55 ` Jakub Kicinski
2023-03-03 16:42 ` [PATCH v2 4/4] net: fix up drivers WRT phy time stamping Köry Maincent
2023-03-03 16:45 ` [PATCH v2 0/4] Up until now, there was no way to let the user select the layer at which time stamping occurs. The stack assumed that PHY time stamping is always preferred, but some MAC/PHY combinations were buggy Köry Maincent
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZANu37JHCKwsiCTT@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=alexandru.tachici@analog.com \
--cc=andrew@lunn.ch \
--cc=andy@greyhouse.net \
--cc=chi.minghao@zte.com.cn \
--cc=claudiu.manoil@nxp.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=grygorii.strashko@ti.com \
--cc=hkallweit1@gmail.com \
--cc=huangguangbin2@huawei.com \
--cc=j.vosburgh@gmail.com \
--cc=kory.maincent@bootlin.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@rempel-privat.de \
--cc=michael@walle.cc \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=qiangqing.zhang@nxp.com \
--cc=richardcochran@gmail.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=vfalico@gmail.com \
--cc=vladimir.oltean@nxp.com \
--cc=wangjie125@huawei.com \
--cc=wangyufen@huawei.com \
--cc=wsa+renesas@sang-engineering.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).