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?
For the former, PTP support was added in commit ece19502834d ("net: phy:
micrel: 1588 support for LAN8814 phy") - first present in v5.18.
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.
