Re: [PATCH net-next 0/3] Add support for 1588 in LAN8814

[Allan W. Nielsen]

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