[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f1d50200-93f5-2c35-933a-01a1e7622983@linux.intel.com>
Date: Wed, 7 Apr 2021 11:32:10 +0300
From: Jarkko Nikula <jarkko.nikula@...ux.intel.com>
To: Yicong Yang <yangyicong@...ilicon.com>, wsa@...nel.org,
andriy.shevchenko@...ux.intel.com, linux-i2c@...r.kernel.org,
Sergey.Semin@...kalelectronics.ru, linux-kernel@...r.kernel.org
Cc: digetx@...il.com, treding@...dia.com, rmk+kernel@...linux.org.uk,
song.bao.hua@...ilicon.com, john.garry@...wei.com,
mika.westerberg@...ux.intel.com, prime.zeng@...wei.com,
linuxarm@...wei.com
Subject: Re: [PATCH v6 3/5] i2c: add support for HiSilicon I2C controller
Hi
On 3/31/21 4:36 PM, Yicong Yang wrote:
> + ret = device_property_read_u64(dev, "clk_rate", &ctlr->clk_rate_khz);
> + if (ret) {
> + dev_err(dev, "failed to get clock frequency, ret = %d\n", ret);
> + return ret;
> + }
> +
> + ctlr->clk_rate_khz = DIV_ROUND_UP_ULL(ctlr->clk_rate_khz, HZ_PER_KHZ);
> +
I'd use a temp variable here for reading the "clk_rate" property in
Hertz and calculating the derived kHz value from it. As a bonus allow to
use u32 for clk_rate_khz instead of u64. u32 will still provide plenty
of headroom :-)
Reason for temp variable is for me it's confusing to see statement like
"rate_khz = rate_khz / 1000".
Jarkko
Powered by blists - more mailing lists