netdev - Re: bnxt_en: Incorrect tx timestamp report

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: <CALs4sv1H=rS96Jq_4i=S0kL57uR6v-sEKbZcqm2VgY6UXbVeMA@mail.gmail.com>
Date: Mon, 24 Mar 2025 20:34:18 +0530
From: Pavan Chebbi <pavan.chebbi@...adcom.com>
To: Michael Chan <michael.chan@...adcom.com>
Cc: Kamil Zaripov <zaripov-kamil@...ide.ai>, Jacob Keller <jacob.e.keller@...el.com>, 
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: bnxt_en: Incorrect tx timestamp report

On Fri, 21 Mar, 2025, 11:03 pm Michael Chan, <michael.chan@...adcom.com>
wrote:

> On Fri, Mar 21, 2025 at 8:17 AM Kamil Zaripov <zaripov-kamil@...ide.ai>
> wrote:
> >
> > > That depends. If it has only one underlying clock, but each PF has its
> > > own register space, it may functionally be independent clocks in
> > > practice. I don't know the bnxt_en driver or hardware well enough to
> > > know if that is the case.
> >
> > > If it really is one clock with one set of registers to control it, then
> > > it should only expose one PHC. This may be tricky depending on the
> > > driver design. (See ice as an example where we've had a lot of
> > > challenges in this space because of the multiple PFs)
> >
> > I can only guess, from looking at the __bnxt_hwrm_ptp_qcfg function,
> > that it depends on hardware and/or firmware (see
> >
> https://elixir.bootlin.com/linux/v6.13.7/source/drivers/net/ethernet/broadcom/bnxt/bnxt.c#L9427-L9431
> ).
> > I hope that broadcom folks can clarify this.
> >
>
> It is one physical PHC per chip.  Each function has access to the
> shared PHC.   It won't work properly when multiple functions try to
> adjust the PHC independently.  That's why we use the non-RTC mode when
> the PHC is shared in multi-function mode.  Pavan can add more details
> on this.
>

Yes, that's correct. It's one PHC shared across functions. The way we
handle multiple
functions accessing the shared PHC is by firmware allowing only one
function to adjust
the frequency. All the other functions' adjustments are ignored. However,
needless to say,
they all still receive the latest timestamps. As I recall, this event
design was an earlier
version of our multi host support implementation where the rollover was
being tracked in
the firmware.

The latest driver handles the rollover on its own and we don't need the
firmware to tell us.
I checked with the firmware team and I gather that the version you are
using is very old.
Firmware version 230.x onwards, you should not receive this event for
rollovers.
Is it possible for you to update the firmware? Do you have access to a more
recent (230+) firmware?

Content of type "text/html" skipped

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4196 bytes)