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:   Tue, 28 Feb 2023 07:16:24 -0800
From:   Richard Cochran <richardcochran@...il.com>
To:     Köry Maincent <kory.maincent@...tlin.com>
Cc:     "Russell King (Oracle)" <linux@...linux.org.uk>, 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?

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.

2. Kconfig: Override PHY default at compile time.

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

4. Letting drivers override PHY at run time.

5. other?

It would be possible to support both 2 and 3, with command line having
the last word.

I don't like #4 because it would cleaner if every time stamping driver
would simply implement the internal APIs, without having special hooks
for various boards.

Thanks,
Richard