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 for Android: free password hash cracker in your pocket

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

Message-ID: <a7d0a9c31e86441b836baf3b5cd7804d@walle.cc>
Date:   Tue, 28 Feb 2023 21:13:57 +0100
From:   Michael Walle <michael@...le.cc>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     andrew@...n.ch, davem@...emloft.net, f.fainelli@...il.com,
        hkallweit1@...il.com, kory.maincent@...tlin.com, kuba@...nel.org,
        maxime.chevallier@...tlin.com, netdev@...r.kernel.org,
        richardcochran@...il.com, thomas.petazzoni@...tlin.com
Subject: Re: [PATCH RFC net-next] net: phy: add Marvell PHY PTP support
 [multicast/DSA issues]

Am 2023-02-28 17:58, schrieb Russell King (Oracle):
> On Tue, Feb 28, 2023 at 05:44:35PM +0100, Michael Walle wrote:
>> >> 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.
>> 
>> Please also consider that there might be one switch with a shared
>> PHC and multiple PHYs, each with its own PHC.
> 
> Doesn't the PTP API already allow that? The PHC is a separate API from
> the network hardware timestamping - and the netdev/PHY is required
> to implement the ethtool get_ts_info API that provides userspace with
> the index to the PHC associated with the interface.

Yes, but the source for the timestamp is the PHC. If the PHCs are
not synchronized, the timestamps won't be either. With a shared PHC,
the synchronization is already a given.

>> In this case, it is a
>> property of the board wether PHY timestamping actually works, because
>> it will need some kind of synchronization between all the PHYs.
> 
> How is this any different from e.g. a platform where there are
> multiple network interfaces each with their own independent PHC
> such as Macchiatobin, where there are two CP110 dies, each with
> their own group of three ethernet adapters, and each die has its
> own PHC shared between the three ethernet adapters?
> 
> Hardware synchronisation between the two PHCs isn't possible, but
> they might tick at the same rate (it's something that hasn't been
> checked.) However, the hardware signals aren't that helpful because
> there's no way to make e.g. the rising edge always be at the start
> of a second. So the synchronisation has to be done in software.
> 
> I don't think PHCs need to be synchronised in hardware to "actually
> work". Take an example of a PC with two network cards, both having
> their own independent PHC.

That might be true if you just want to use PTP as a time sync protocol,
but keep in mind that there is also the time aware scheduler which uses
the PHC as its time source, too. If you want to use PHY timestamping
in this case, the PHCs needs to be synchronized. Honestly, I'm not 
really
sure, how that is supposed to work.
All I'm trying to say, is there might also be some board constraints so
the MAC driver might not always be telling what is best, PHY or MAC.

-michael