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]

Date:   Fri, 3 Mar 2023 14:03:03 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Michael Walle <michael@...le.cc>, 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]

On Fri, Mar 03, 2023 at 02:20:20PM +0100, Andrew Lunn 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?
> 
> 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.

I thought (4) was what we have been discussing... but the problem
seems to be that folk want to drill down into the fine detail about
whether PHY or MAC timestamping is better than the other.

As I've already stated, I doubt DT maintainers will wear having a
DT property for this, on the grounds that it's very much a software
control rather than a hardware description.

On the other hand, if DT described the connectivity of the PTP
hardware signals, then one could probably make a decision based
upon that, and as that's describing hardware, it would be less
problematical during DT review.

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