Messages in this thread | | | Date | Fri, 10 Mar 2023 21:48:48 +0100 | From | Michael Walle <> | Subject | Re: [PATCH v3 3/5] net: Let the active time stamping layer be selectable. |
| |
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
| |