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: <Y/4exYkeQF2wOTkD@lunn.ch>
Date:   Tue, 28 Feb 2023 16:33:25 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     Köry Maincent <kory.maincent@...tlin.com>,
        "Russell King (Oracle)" <linux@...linux.org.uk>,
        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]

> 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.

There are also lots of systems which don't use DT, e.g. ACPI, or are
just plain PCI or USB devices which don't have any configuration at
all.

> 2. Kconfig: Override PHY default at compile time.

Per MAC/PHY combination? That does not scale.

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

Module params are consider bad in the networking stack. DaveM always
NACKs them.

> 4. Letting drivers override PHY at run time.

This is what Russell suggested.

> 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.

I agree that stamping drivers should implement the API. All i think
Russell is suggesting is that MAC drivers have an API call they can
make on the PTP core to tell it to direct all calls to the MAC
implementation of the time stamper, not the PHY implementation of the
time stamper. This might need some changes to the internal APIs, such
that all kernel API calls should go through the PTP core, and the PTP
core then directs them by default to the PHY, but on request sends it
to the MAC stamper.

     Andrew