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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y/4DZIDm1d74MuFJ@shell.armlinux.org.uk>
Date:   Tue, 28 Feb 2023 13:36:36 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Köry Maincent <kory.maincent@...tlin.com>
Cc:     Richard Cochran <richardcochran@...il.com>, andrew@...n.ch,
        davem@...emloft.net, f.fainelli@...il.com, hkallweit1@...il.com,
        kuba@...nel.org, netdev@...r.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Maxime Chevallier <maxime.chevallier@...tlin.com>
Subject: Re: [PATCH RFC net-next] net: phy: add Marvell PHY PTP support
 [multicast/DSA issues]

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@...linux.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?
> 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 only thought I have is that maybe a MAC driver should be able to
override the default, then at least we have a way to deal with this
on a case by case basis. However, that's just pulling an idea out of
the air.

I think what might be useful as a first step is to go through the
various networking devices to work out which support PTP today, and
tabulate the result. There shouldn't be any cases where we have both
the MAC and PHY having PTP support (for the API reasons I've already
stated) but if there are, that needs to be highlighted.

Then we can see what the default should be, and then which MAC
drivers would need to override the default.

It would probably be a good idea to document that in the kernel's
Documentation subdirectory so when e.g. a PHY driver gains PTP
support, we have some idea which MAC drivers may be impacted.

Does that sound sensible?

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