Re: [PATCH RFC net-next] net: phy: add Marvell PHY PTP support [multicast/DSA issues]

[Andrew Lunn <andrew@lunn.ch>]

On Fri, Mar 03, 2023 at 02:34:55PM +0100, Köry Maincent wrote:
> On Fri, 3 Mar 2023 14:20:20 +0100
> Andrew Lunn <andrew@lunn.ch> wrote:
> 
> > I'm not sure we are making much progress here...
> > 
> > Lets divide an conquer. As far as i can see we have the following bits
> > of work to do:
> > 
> > 1) Kernel internal plumbing to allow multiple time stampers for one
> > netdev. The PTP core probably needs to be the mux for all kAPI calls,
> > and any internal calling between components. This might mean changes
> > to all MAC drivers supporting PTP and time stampers. But i don't think
> > there is anything too controversial here, just plumbing work.
> > 
> > 2) Some method to allow user space to control which time stamper is
> > used. Either an extension of the existing IOCTL interface, or maybe
> > ethtool. Depending on how ambitious we want to be, add a netlink API
> > to eventually replace the IOCTL interface?
> 
> Isn't the patch series (with small revisions) from Richard sufficient for this
> two points?
> https://lkml.kernel.org/netdev/Y%2F0N4ZcUl8pG7awc@shell.armlinux.org.uk/

I've not looked at it. How about you make the small revisions and post
it. So long as the Marvell PHY PTP code is not merged, it should be
safe to work on these parts and not cause regressions.

> > 3) Add a device tree binding to control which time stamper is
> > used. Probably a MAC property. Also probably not too controversial.
> > 
> > 4) Some solution to the default choice if there is no DT property.
> 
> And in cases of architectures which do not support DT how do we deal with it?

x86 has ACPI. It seems like ACPI folks are happy to simply stuff DT
properties into ACPI nodes, rather than come up with a native ACPI
way. But we don't really need to support ACPI until somebody has an
ACPI board which needs to configure the time stamper.

Harder is things like USB, which mostly never has DT properties. But a
USB dongle tends to have known components, both the MAC and the PHY is
known, and so the dongle driver could make a call into the PTP core to
select which time stamper should be used. But i would suggest we solve
this problem when we actually reach it, not now.

     Andrew