Re: [PATCH v3 3/5] net: Let the active time stamping layer be selectable.

[Michael Walle <michael@walle.cc>]

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