Hi, On Thu, Mar 17, 2022 at 01:16:50PM +0100, Michael Walle wrote: > From: patchwork-bot+netdevbpf@xxxxxxxxxx > > 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
