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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux