netdev - RE: [net-next 14/14] ptp: xgbe: convert to .adjfine and adjust_by_scaled

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: <CO1PR11MB5089E76BE2538C85827C0386D66C9@CO1PR11MB5089.namprd11.prod.outlook.com>
Date:   Fri, 19 Aug 2022 21:04:18 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Tom Lendacky <thomas.lendacky@....com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "K. Y. Srinivasan" <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Wei Liu <wei.liu@...nel.org>,
        "Cui, Dexuan" <decui@...rosoft.com>,
        Shyam Sundar S K <Shyam-sundar.S-k@....com>,
        "David S. Miller" <davem@...emloft.net>,
        "Eric Dumazet" <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Siva Reddy Kallam <siva.kallam@...adcom.com>,
        "Prashant Sreedharan" <prashant@...adcom.com>,
        Michael Chan <mchan@...adcom.com>,
        "Yisen Zhuang" <yisen.zhuang@...wei.com>,
        Salil Mehta <salil.mehta@...wei.com>,
        "Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        Tariq Toukan <tariqt@...dia.com>,
        "Saeed Mahameed" <saeedm@...dia.com>,
        Leon Romanovsky <leon@...nel.org>,
        "Bryan Whitehead" <bryan.whitehead@...rochip.com>,
        Sergey Shtylyov <s.shtylyov@....ru>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        "Alexandre Torgue" <alexandre.torgue@...s.st.com>,
        Jose Abreu <joabreu@...opsys.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Richard Cochran <richardcochran@...il.com>,
        "Thampi, Vivek" <vithampi@...are.com>,
        "VMware PV-Drivers Reviewers" <pv-drivers@...are.com>,
        Jie Wang <wangjie125@...wei.com>,
        Guangbin Huang <huangguangbin2@...wei.com>,
        "Eran Ben Elisha" <eranbe@...dia.com>, Aya Levin <ayal@...dia.com>,
        Cai Huoqing <cai.huoqing@...ux.dev>,
        Biju Das <biju.das.jz@...renesas.com>,
        Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
        Phil Edworthy <phil.edworthy@...esas.com>,
        Jiasheng Jiang <jiasheng@...as.ac.cn>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Wan Jiabing <wanjiabing@...o.com>,
        Lv Ruyi <lv.ruyi@....com.cn>, Arnd Bergmann <arnd@...db.de>
Subject: RE: [net-next 14/14] ptp: xgbe: convert to .adjfine and
 adjust_by_scaled_ppm



> -----Original Message-----
> From: Tom Lendacky <thomas.lendacky@....com>
> Sent: Friday, August 19, 2022 9:05 AM
> To: Keller, Jacob E <jacob.e.keller@...el.com>; netdev@...r.kernel.org
> Cc: K. Y. Srinivasan <kys@...rosoft.com>; Haiyang Zhang
> <haiyangz@...rosoft.com>; Stephen Hemminger <sthemmin@...rosoft.com>;
> Wei Liu <wei.liu@...nel.org>; Cui, Dexuan <decui@...rosoft.com>; Shyam
> Sundar S K <Shyam-sundar.S-k@....com>; David S. Miller
> <davem@...emloft.net>; Eric Dumazet <edumazet@...gle.com>; Jakub Kicinski
> <kuba@...nel.org>; Paolo Abeni <pabeni@...hat.com>; Siva Reddy Kallam
> <siva.kallam@...adcom.com>; Prashant Sreedharan
> <prashant@...adcom.com>; Michael Chan <mchan@...adcom.com>; Yisen
> Zhuang <yisen.zhuang@...wei.com>; Salil Mehta <salil.mehta@...wei.com>;
> Brandeburg, Jesse <jesse.brandeburg@...el.com>; Nguyen, Anthony L
> <anthony.l.nguyen@...el.com>; Tariq Toukan <tariqt@...dia.com>; Saeed
> Mahameed <saeedm@...dia.com>; Leon Romanovsky <leon@...nel.org>;
> Bryan Whitehead <bryan.whitehead@...rochip.com>; Sergey Shtylyov
> <s.shtylyov@....ru>; Giuseppe Cavallaro <peppe.cavallaro@...com>;
> Alexandre Torgue <alexandre.torgue@...s.st.com>; Jose Abreu
> <joabreu@...opsys.com>; Maxime Coquelin <mcoquelin.stm32@...il.com>;
> Richard Cochran <richardcochran@...il.com>; Thampi, Vivek
> <vithampi@...are.com>; VMware PV-Drivers Reviewers <pv-
> drivers@...are.com>; Jie Wang <wangjie125@...wei.com>; Guangbin Huang
> <huangguangbin2@...wei.com>; Eran Ben Elisha <eranbe@...dia.com>; Aya
> Levin <ayal@...dia.com>; Cai Huoqing <cai.huoqing@...ux.dev>; Biju Das
> <biju.das.jz@...renesas.com>; Lad Prabhakar <prabhakar.mahadev-
> lad.rj@...renesas.com>; Phil Edworthy <phil.edworthy@...esas.com>; Jiasheng
> Jiang <jiasheng@...as.ac.cn>; Gustavo A. R. Silva <gustavoars@...nel.org>; Linus
> Walleij <linus.walleij@...aro.org>; Wan Jiabing <wanjiabing@...o.com>; Lv Ruyi
> <lv.ruyi@....com.cn>; Arnd Bergmann <arnd@...db.de>
> Subject: Re: [net-next 14/14] ptp: xgbe: convert to .adjfine and
> adjust_by_scaled_ppm
> 
> On 8/18/22 17:27, Jacob Keller wrote:
> > The xgbe implementation of .adjfreq is implemented in terms of a
> > straight forward "base * ppb / 1 billion" calculation.
> >
> > Convert this driver to .adjfine and use adjust_by_scaled_ppm to calculate
> > the new addend value.
> >
> > Signed-off-by: Jacob Keller <jacob.e.keller@...el.com>
> > Cc: Tom Lendacky <thomas.lendacky@....com>
> > Cc: Shyam Sundar S K <Shyam-sundar.S-k@....com>
> > ---
> >
> > I do not have this hardware, and have only compile tested the change.
> >
> >   drivers/net/ethernet/amd/xgbe/xgbe-ptp.c | 20 ++++----------------
> >   1 file changed, 4 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-ptp.c
> b/drivers/net/ethernet/amd/xgbe/xgbe-ptp.c
> > index d06d260cf1e2..7051bd7cf6dc 100644
> > --- a/drivers/net/ethernet/amd/xgbe/xgbe-ptp.c
> > +++ b/drivers/net/ethernet/amd/xgbe/xgbe-ptp.c
> > @@ -134,27 +134,15 @@ static u64 xgbe_cc_read(const struct cyclecounter
> *cc)
> >   	return nsec;
> >   }
> >
> > -static int xgbe_adjfreq(struct ptp_clock_info *info, s32 delta)
> > +static int xgbe_adjfine(struct ptp_clock_info *info, long scaled_ppm)
> >   {
> >   	struct xgbe_prv_data *pdata = container_of(info,
> >   						   struct xgbe_prv_data,
> >   						   ptp_clock_info);
> >   	unsigned long flags;
> > -	u64 adjust;
> > -	u32 addend, diff;
> > -	unsigned int neg_adjust = 0;
> > +	u64 addend;
> >
> > -	if (delta < 0) {
> > -		neg_adjust = 1;
> > -		delta = -delta;
> > -	}
> > -
> > -	adjust = pdata->tstamp_addend;
> > -	adjust *= delta;
> > -	diff = div_u64(adjust, 1000000000UL);
> > -
> > -	addend = (neg_adjust) ? pdata->tstamp_addend - diff :
> > -				pdata->tstamp_addend + diff;
> > +	addend = adjust_by_scaled_ppm(pdata->tstamp_addend, scaled_ppm);
> 
> Since addend is now a u64, but the called function just afterwards,
> xgbe_update_tstamp_addend(), expects an unsigned int, won't this generate
> a compiler warning depending on the flags used?
> 

It doesn't seem to generate anything with W=1 or W=2 on my system. Its possible that the compiler can deduce that this won't overflow a u32?

We could add a check to ensure it doesn't overflow the u32 size?

> Thanks,
> Tom
> 
> >
> >   	spin_lock_irqsave(&pdata->tstamp_lock, flags);
> >
> > @@ -235,7 +223,7 @@ void xgbe_ptp_register(struct xgbe_prv_data *pdata)
> >   		 netdev_name(pdata->netdev));
> >   	info->owner = THIS_MODULE;
> >   	info->max_adj = pdata->ptpclk_rate;
> > -	info->adjfreq = xgbe_adjfreq;
> > +	info->adjfine = xgbe_adjfine;
> >   	info->adjtime = xgbe_adjtime;
> >   	info->gettime64 = xgbe_gettime;
> >   	info->settime64 = xgbe_settime;