On Fri, Jun 14, 2024 at 04:02:04PM +0200, Paolo Abeni wrote: > On Wed, 2024-06-12 at 17:04 +0200, Kory Maincent wrote: > > In prevision to add new UAPI for hwtstamp we will be limited to the struct > > ethtool_ts_info that is currently passed in fixed binary format through the > > ETHTOOL_GET_TS_INFO ethtool ioctl. It would be good if new kernel code > > already started operating on an extensible kernel variant of that > > structure, similar in concept to struct kernel_hwtstamp_config vs struct > > hwtstamp_config. > > > > Since struct ethtool_ts_info is in include/uapi/linux/ethtool.h, here > > we introduce the kernel-only structure in include/linux/ethtool.h. > > The manual copy is then made in the function called by ETHTOOL_GET_TS_INFO. > > > > Acked-by: Shannon Nelson <shannon.nelson@xxxxxxx> > > Acked-by: Alexandra Winter <wintera@xxxxxxxxxxxxx> > > Signed-off-by: Kory Maincent <kory.maincent@xxxxxxxxxxx> > > I think it would be nice if a few more vendors could actually step-in > and test/ack the driver specific bits. Well, in part this series was triggered because of an issue having PTP support in Marvell's PP2 driver, and then the issue that if we add it to the Marvell PHY driver, the platforms that are currently using the PP2 based PTP support were forced into the weird situation that some of the PTP calls hit the PP2 driver and others hit the PHY driver. I had sent Kory an email a couple of weeks ago saying that I'm unlikely to be able to test this out in that setup any time soon, I've had high work pressure for the last seven-ish weeks, and I would need to be in front of the hardware, which is fairly rare at the moment, and I'm not going to be in front of the hardware until August. So I'm just not going to be able to test it in a reasonable time scale. There's not a lot I can do about that, sorry. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
