netdev - Re: [PATCH net 8/9] bnxt_en: Move bnxt_ptp_init() to bnxt

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]

Message-ID: <20210719170728.GB5568@hoboy.vegasvil.org>
Date:   Mon, 19 Jul 2021 10:07:28 -0700
From:   Richard Cochran <richardcochran@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Michael Chan <michael.chan@...adcom.com>, davem@...emloft.net,
        netdev@...r.kernel.org, gospo@...adcom.com
Subject: Re: [PATCH net 8/9] bnxt_en: Move bnxt_ptp_init() to bnxt_open()

On Mon, Jul 19, 2021 at 12:43:23PM +0200, Jakub Kicinski wrote:
> On Sun, 18 Jul 2021 15:36:32 -0400, Michael Chan wrote:
> > The device needs to be in ifup state for PTP to function, so move
> > bnxt_ptp_init() to bnxt_open().  This means that the PHC will be
> > registered during bnxt_open().
> 
> I think it's an anti-pattern to have the clock registered only when
> the device is up. Right, Richard?

Yes, indeed.

> IIRC Intel parts did it in the past because they had the clock hooked
> up to the MAC/PHY so the clock was not actually ticking. But seems like
> a wrong trade off to unreg PTP for SW convenience. Or maybe I'm
> biased against the live FW reset :) Let's see if Richard agrees.

Totally agree!

Ideally the PHC appears as soon as the driver instantiates for a HW
device.  Telling time from the clock is independent from the network
interface being up or down.

Some drivers are lazy and fail to decouple these two orthogonal
issues.  In some (all?) cases, there is no HW limitation involved,
just sloppy driver work.

Thanks,
Richard