Thread (24 messages) 24 messages, 4 authors, 2023-08-01

Re: [PATCH v8 net-next 12/12] net: remove phy_has_hwtstamp() -> phy_mii_ioctl() decision from converted drivers

From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: 2023-07-18 14:47:07
Also in: linux-arm-kernel, lkml

On Tue, Jul 18, 2023 at 03:38:27PM +0100, Russell King (Oracle) wrote:
On Mon, Jul 17, 2023 at 06:27:09PM +0300, Vladimir Oltean wrote:
quoted
+static int dev_set_hwtstamp_phylib(struct net_device *dev,
+				   struct kernel_hwtstamp_config *cfg,
+				   struct netlink_ext_ack *extack)
+{
+	const struct net_device_ops *ops = dev->netdev_ops;
+	bool phy_ts = phy_has_hwtstamp(dev->phydev);
+	struct kernel_hwtstamp_config old_cfg = {};
+	bool changed = false;
+	int err;
+
+	cfg->source = phy_ts ? HWTSTAMP_SOURCE_PHYLIB : HWTSTAMP_SOURCE_NETDEV;
+
+	if (!phy_ts || (dev->priv_flags & IFF_SEE_ALL_HWTSTAMP_REQUESTS)) {
I suppose the idea here is that for something like mvpp2, which when we
have PTP support for Marvell PHYs in general will want to prefer to use
the MAC-based PTP rather than PHY-based, that driver needs to set
IFF_SEE_ALL_HWTSTAMP_REQUESTS so that the ndo timestamp ops always get
called? I didn't see this discussed in the commit message for this
patch.
No; the plan for mvpp2-like situations is for Köry to:

- add UAPI to allow specifying the timestamping source (based on PHC ID,
  aka /dev/ptpN, probably)

- change the core policy (effectively this function) to prefer:
  - netdev-based timestamping by default (this reverses the current policy,
    to prevent future regressions when more phylib drivers gain
    timestamping support)
  - phylib-based timestamping for a selection of whitelisted phylib PHYs
    (this avoids regressions with existing phylib-based systems)
  - the user choice

The only thing that IFF_SEE_ALL_HWTSTAMP_REQUESTS does is to give the
netdev a hook for phylib timestamping operations, for completely
unrelated purposes (switch ports that become PTP-aware must stop
flooding PTP packets).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help