lkml.org 
[lkml]   [2023]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2023-03-27 00:53    [W:0.123 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site