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: <bef7f3e7-3383-8ef0-73b4-156e1bc57d94@amd.com>
Date:   Mon, 22 Aug 2022 15:47:54 -0500
From:   Tom Lendacky <thomas.lendacky@....com>
To:     "Keller, Jacob E" <jacob.e.keller@...el.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

On 8/19/22 16:04, Keller, Jacob E wrote:
>> -----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?

As long as we don't see a warning, I'm ok with it.

Acked-by: Tom Lendacky <thomas.lendacky@....com>

Thanks,
Tom

> 
>> 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;

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ