[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACKFLinG2s5HVisa7YoWAZByty0AyCqO-gixAE8FSwVHKK8cjQ@mail.gmail.com>
Date: Fri, 21 Mar 2025 10:33:07 -0700
From: Michael Chan <michael.chan@...adcom.com>
To: Kamil Zaripov <zaripov-kamil@...ide.ai>
Cc: Jacob Keller <jacob.e.keller@...el.com>, netdev@...r.kernel.org
Subject: Re: bnxt_en: Incorrect tx timestamp report
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.
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4196 bytes)
Powered by blists - more mailing lists