On Thu, Mar 17, 2022 at 03:05:59PM +0100, Allan W. Nielsen wrote: > 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. I assume this is in net-next. So we have two weeks of the merge window followed by around 7 weeks of the -rc in order to clean this up. It is only when the code is released in a final kernel does it become an ABI. > 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. Patches would be good. Ideally the patches would be posted in the next couple of weeks, even if we do have a lot longer. > The elefant in the room is the 'lan8814_latencies' structure containing > the default latency values in the driver, which Richard is unhappy with. The important thing is getting the ABI fixed. So the DT properties need to be removed, etc. To some extend the corrections are ABI. If the corrections change the user space configuration also needs to change when trying to get the best out of the hardware. So depending on how long the elefant is around, it might make sense to actually do a revert, or at minimum disabling PTP, so time can be spent implementing new APIs or whatever is decided. So i would suggest a two pronged attach: Fixup patchs Try to bring the discussion to a close and implement whatever is decided. Andrew
