On Thu, Mar 17, 2022 at 03:38:50PM +0100, Andrew Lunn wrote: > 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. We will do that. > 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. ACK. > So i would suggest a two pronged attach: > > Fixup patchs > Try to bring the discussion to a close and implement whatever is decided. Make sense - we will do the fix-ups and try restart the dicussion. -- /Allan
