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

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

On Mon, Feb 27, 2023 at 06:30:13PM +0100, Köry Maincent wrote:
> On Mon, 27 Feb 2023 15:20:05 +0000
> "Russell King (Oracle)" <linux@armlinux.org.uk> wrote:
> 
> > > I see this patch has been abandoned.
> > > I am testing it with a ZynqMP board (macb ethernet) and it seems to more or
> > > less work. It got tx timestamp timeout at initialization but after some
> > > times (~20 seconds) ptp4l manages to set it working. Also the IEEE 802.3
> > > network PTP mode is not working, it constantly throw rx timestamp overrun
> > > errors.
> > > I will aim at fixing these issues and adding support to interrupts. It
> > > would be good to have it accepted mainline. What do you think is missing
> > > for that?  
> > 
> > It isn't formally abandoned, but is permanently on-hold as merging
> > Marvell PHY PTP support into mainline _will_ regress the superior PTP
> > support on the Macchiatobin platform for the reasons outlined in:
> > 
> > https://lore.kernel.org/netdev/20200729220748.GW1605@shell.armlinux.org.uk/
> > 
> > Attempting to fix this problem was basically rejected by the PTP
> > maintainer, and thus we're at a deadlock over the issue, and Marvell
> > PHY PTP support can never be merged into mainline.
> 
> As I understand, if the PHY support PTP, it is prioritize to the PTP of the MAC.
> As quote in the mail thread it seems there was discussion in netdev about
> moving phy_has_hwtstamp to core and allowing ethtool to choose which one to
> use. I don't know if the decision have been made about it since, but it seems
> nothing has been sent to mainline. Meanwhile, why do we not move forward on
> this patch with the current PTP behavior and updates it when new core PTP change
> will be sent mailine?

Clearly, we have an issue with communication. Let me repeat:

Merging support for Marvell PHY PTP *will* *regress* the Macchiatobin
platform, making PTP *unusable* because *some* API calls will go to
the *PHY* PTP instance while *other* API calls go to the *MAC* PTP
instance.

Since merging Marvell PHY PTP support will cause a regression, the only
way to fix that regression at the moment is by reverting the merge of
Marvell PHY PTP support as there is no acceptable solution to the above
problem - I've attempted to fix it and the patch was rejected.

Sorry, but no, mainline does not get Marvell PHY PTP support before
the generic code is fixed for this blocking issue.

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