netdev - Re: [PATCH net-next] bnxt_en: support PPS in/out on all pins

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: <CALs4sv3OV-VVYS7oy1akiZdQncsmqY+hqds7NLeiy3oh3Awz8w@mail.gmail.com>
Date: Fri, 17 Oct 2025 19:38:07 +0530
From: Pavan Chebbi <pavan.chebbi@...adcom.com>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Cc: Michael Chan <michael.chan@...adcom.com>, Jakub Kicinski <kuba@...nel.org>, 
	Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, 
	Richard Cochran <richardcochran@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] bnxt_en: support PPS in/out on all pins

On Fri, Oct 17, 2025 at 4:10 PM Vadim Fedorenko
<vadim.fedorenko@...ux.dev> wrote:
>
> On 17/10/2025 10:15, Pavan Chebbi wrote:
> > On Fri, Oct 17, 2025 at 2:21 PM Vadim Fedorenko
> > <vadim.fedorenko@...ux.dev> wrote:
> >>
> >> On 17.10.2025 04:45, Pavan Chebbi wrote:
> >>> On Fri, Oct 17, 2025 at 3:54 AM Vadim Fedorenko
> >>> <vadim.fedorenko@...ux.dev> wrote:
> >>>>
> >>>> n_ext_ts and n_per_out from ptp_clock_caps are checked as a max number
> >>>> of pins rather than max number of active pins.
> >>>
> >>> I am not 100pc sure. How is n_pins going to be different then?
> >>> https://elixir.bootlin.com/linux/v6.17/source/include/linux/ptp_clock_kernel.h#L69
> >>
> >> So in general it's more for the case where HW has pins connected through mux to
> >> the DPLL channels. According to the bnxt_ptp_cfg_pin() bnxt HW has pins
> >> hardwired to channels and NVM has pre-defined configuration of pins' functions.
> >>
> >> [host ~]# ./testptp -d /dev/ptp2 -l
> >> name bnxt_pps0 index 0 func 0 chan 0
> >> name bnxt_pps1 index 1 func 0 chan 1
> >> name bnxt_pps2 index 2 func 0 chan 2
> >> name bnxt_pps3 index 3 func 0 chan 3
> >>
> >> without the change user cannot configure EXTTS or PEROUT function on pins
> >> 1-3 preserving channels 1-3 on them.
> >>
> >> The user can actually use channel 0 on every pin because bnxt driver doesn't
> >> care about channels at all, but it's a bit confusing that it sets up different
> >> channels during init phase.
> >
> > You are right that we don't care about the channels. So I think
> > ideally it should have been set to 0 for all the pins.
> > Does that not make a better fix? Meaning to say, we don't care about
> > the channel but/therefore please use 0 for all pins.
> > What I am not sure about the proposed change in your patch is that it
> > may be overriding the definition of the n_ext_ts and n_per_out in
> > order to provide flexibility to users to change channels, no?
>
> Well, yeah, the overriding exists, but that's mostly the artifact of not
> so flexible API. But I agree, we can improve init part to make it clear.
> But one more thing has just come to my mind - is it
> really possible to configure PPS-in/PPS-out on pins 0-1?
> AFAIU, there are functions assigned to each pin, which can only be
> enabled or disabled by the user-space app, and in this case
> bnxt_ptp_verify() should be improved to validate function per pin,
> right?
>
The pin config was really flexible because we implemented it first for
575xx chipsets. We could remap the functions on Thor1.
With 576xx, what you are saying is true. The pin functions are fixed.
If the user is aware of the functions, then it's not a problem.
But yes, because there is verify() available, we can always validate.
So we can improve the bnxt_ptp_verify()

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