Am 2023-03-10 17:06, schrieb Vladimir Oltean:
On Fri, Mar 10, 2023 at 02:34:07PM +0100, Michael Walle wrote:
Yeah, but my problem right now is, that if this discussion won't find
any good solution, the lan8814 phy timestamping will find it's way
into an official kernel and then it is really hard to undo things.
So, I'd really prefer to *first* have a discussion how to proceed
with the PHY timestamping and then add the lan8814 support, so
existing boards don't show a regressions.
You don't mean LAN8814 but LAN8841, no?
Ohh, I'm stupid. No, I mean the LAN8814 (Quad PHY).
For the former, PTP support was added in commit ece19502834d ("net:
phy:
micrel: 1588 support for LAN8814 phy") - first present in v5.18.
Yeah and I remember.. there was some kind of issue with the PHY
latencies. Ok, looks like I'm screwed then. I wonder how Microchip
is doing it, because our board is almost an identical copy of the
reference system.
For the latter, it was commit cafc3662ee3f ("net: micrel: Add PHC
support for lan8841"), and this one indeed is in the v6.3 release
candidates.
Assuming you can prove a regression, how about adding the PHY driver
whitelist *without* the lan8841 as a patch to net.git? (blaming commit
cafc3662ee3f ("net: micrel: Add PHC support for lan8841")).
Doing this will effectively deactivate lan8841 PHY timestamping without
reverting the code. Then, this PHY timestamping support could be
activated back in net-next, based on some sort of explicit UAPI call.
Sorry for the noise and any inconvenience,
-michael
