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