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

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Tue, Feb 28, 2023 at 07:16:24AM -0800, Richard Cochran wrote:
> On Tue, Feb 28, 2023 at 02:16:30PM +0100, Köry Maincent wrote:
> > On Tue, 28 Feb 2023 12:07:09 +0000
> > "Russell King (Oracle)" <linux@armlinux.org.uk> wrote:
> > > So yes, it's a nice idea to support multiple hardware timestamps, but
> > > I think that's an entirely separate problem to solving the current
> > > issue, which is a blocking issue to adding support for PTP on some
> > > platforms.
> > 
> > Alright, Richard can I continue your work on it and send new revisions of your
> > patch series or do you prefer to continue on your own?
> 
> If you can work this, please do.  I can help review and test.
> 
> > Also your series rise the question of which timestamping should be the default,
> > MAC or PHY, without breaking any past or future compatibilities.
> > There is question of using Kconfig or devicetree but each of them seems to have
> > drawbacks:
> > https://lore.kernel.org/netdev/ad4a8d3efbeaacf241a19bfbca5976f9@walle.cc/ 
> > 
> > Do you or Russell have any new thought about it?
> 
> The overall default must be PHY, because that is the legacy condition.
> The options to change the default are:
> 
> 1. device tree: Bad because the default is a configuration and does
>    not describe the hardware.

I'm quite sure the DT maintainers will frown upon that.

> 2. Kconfig: Override PHY default at compile time.

That doesn't work for Arm (32 or 64 bit) kernels as we want a single
kernel image that will work correctly on any platform, so as soon as
we have two platforms that needs the Kconfig set differently, this
becomes a problem.

> 3. Module Param: Configure default on kernel command line.

I understand module parameters are frowned upon by netdev.

> 4. Letting drivers override PHY at run time.

I think this is the only sensible solution - we know for example that
mvpp2 will prefer its PTP implementation as it is (a) higher resolution
and (b) has more flexibility than what can be provided by the Marvell
PHYs that it is often used with.

> 5. other?

Another possible solution to this would be to introduce a rating for
each PTP clock in a similar way that we do for the kernel's
clocksources, and the one with the highest rating becomes the default. 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!