[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220317140559.f52cuvw6gswyrfn6@den-dk-m31684h>
Date: Thu, 17 Mar 2022 15:05:59 +0100
From: "Allan W. Nielsen" <allan.nielsen@...rochip.com>
To: Michael Walle <michael@...le.cc>
CC: <patchwork-bot+netdevbpf@...nel.org>,
<Divya.Koppera@...rochip.com>, <UNGLinuxDriver@...rochip.com>,
<andrew@...n.ch>, <davem@...emloft.net>,
<devicetree@...r.kernel.org>, <hkallweit1@...il.com>,
<kuba@...nel.org>, <linux-kernel@...r.kernel.org>,
<linux@...linux.org.uk>, <madhuri.sripada@...rochip.com>,
<manohar.puri@...rochip.com>, <netdev@...r.kernel.org>,
<richardcochran@...il.com>, <robh+dt@...nel.org>
Subject: Re: [PATCH net-next 0/3] Add support for 1588 in LAN8814
Hi,
On Thu, Mar 17, 2022 at 01:16:50PM +0100, Michael Walle wrote:
> From: patchwork-bot+netdevbpf@...nel.org
> > Here is the summary with links:
> > - [net-next,1/3] net: phy: micrel: Fix concurrent register access
> > https://git.kernel.org/netdev/net-next/c/4488f6b61480
> > - [net-next,2/3] dt-bindings: net: micrel: Configure latency values and timestamping check for LAN8814 phy
> > https://git.kernel.org/netdev/net-next/c/2358dd3fd325
> > - [net-next,3/3] net: phy: micrel: 1588 support for LAN8814 phy
> > https://git.kernel.org/netdev/net-next/c/ece19502834d
>
> I'm almost afraid to ask.. but will this series be reverted (or
> the device tree bindings patch)? There were quite a few remarks, even
> about the naming of the properties. So, will it be part of the next
> kernel release or will it be reverted?
Thanks for bringing this up - was about to ask myself.
Not sure what is the normal procedure here.
If not reverted, we can do a patch to remove the dt-bindings (and also
the code in the driver using them). Also, a few other minor comments was
given and we can fix those.
The elefant in the room is the 'lan8814_latencies' structure containing
the default latency values in the driver, which Richard is unhappy with.
Russell indicated that he prefere having these numbers in the driver
rather than hiding them in firmware (lan8814 does not have firmware, so
not an option).
Andrew sugegsted adding additional APIs to let ptp4l control if
time-stamps should be calibrated in HW/Kernel or in userspace. Likely
something like that can be done - but I did not get the impression that
this is what Richard would like to see either.
Also, I would like drivers to come with default latency numbers which
are good enough for most (and the rest will need to calibrate and
compensate further using the hooks and handles in userspace).
What would you like to see - believe you will also be a user of this?
--
/Allan
Powered by blists - more mailing lists