lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 17 Mar 2022 15:05:59 +0100
From:   "Allan W. Nielsen" <allan.nielsen@...rochip.com>
To:     Michael Walle <michael@...le.cc>
CC:     <patchwork-bot+netdevbpf@...nel.org>,
        <Divya.Koppera@...rochip.com>, <UNGLinuxDriver@...rochip.com>,
        <andrew@...n.ch>, <davem@...emloft.net>,
        <devicetree@...r.kernel.org>, <hkallweit1@...il.com>,
        <kuba@...nel.org>, <linux-kernel@...r.kernel.org>,
        <linux@...linux.org.uk>, <madhuri.sripada@...rochip.com>,
        <manohar.puri@...rochip.com>, <netdev@...r.kernel.org>,
        <richardcochran@...il.com>, <robh+dt@...nel.org>
Subject: Re: [PATCH net-next 0/3] Add support for 1588 in LAN8814

Hi,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ