[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <202305081759.wgN4Q80I-lkp@intel.com>
Date: Mon, 8 May 2023 17:48:29 +0800
From: kernel test robot <lkp@...el.com>
To: Nylon Chen <nylon.chen@...ive.com>, aou@...s.berkeley.edu,
conor@...nel.org, emil.renner.berthing@...onical.com,
geert+renesas@...der.be, heiko@...ech.de,
krzysztof.kozlowski+dt@...aro.org, palmer@...belt.com,
paul.walmsley@...ive.com, robh+dt@...nel.org,
thierry.reding@...il.com, u.kleine-koenig@...gutronix.de,
devicetree@...r.kernel.org, linux-pwm@...r.kernel.org,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Cc: oe-kbuild-all@...ts.linux.dev, nylon.chen@...ive.com,
nylon7717@...il.com, zong.li@...ive.com, greentime.hu@...ive.com,
vincent.chen@...ive.com, Conor Dooley <conor.dooley@...rochip.com>
Subject: Re: [PATCH v3 2/2] pwm: sifive: change the PWM controlled LED
algorithm
Hi Nylon,
kernel test robot noticed the following build warnings:
[auto build test WARNING on robh/for-next]
[also build test WARNING on thierry-reding-pwm/for-next rockchip/for-next linus/master v6.4-rc1 next-20230508]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Nylon-Chen/riscv-dts-sifive-unleashed-unmatched-Remove-PWM-controlled-LED-s-active-low-properties/20230420-173619
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link: https://lore.kernel.org/r/20230420093457.18936-3-nylon.chen%40sifive.com
patch subject: [PATCH v3 2/2] pwm: sifive: change the PWM controlled LED algorithm
config: powerpc-randconfig-s041-20230507 (https://download.01.org/0day-ci/archive/20230508/202305081759.wgN4Q80I-lkp@intel.com/config)
compiler: powerpc-linux-gcc (GCC) 12.1.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.4-39-gce1a6720-dirty
# https://github.com/intel-lab-lkp/linux/commit/f2d706bf61190a45a8f90f1f455bc943d4ac7b6e
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Nylon-Chen/riscv-dts-sifive-unleashed-unmatched-Remove-PWM-controlled-LED-s-active-low-properties/20230420-173619
git checkout f2d706bf61190a45a8f90f1f455bc943d4ac7b6e
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=powerpc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=powerpc SHELL=/bin/bash drivers/pwm/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@...el.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202305081759.wgN4Q80I-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/pwm/pwm-sifive.c:157:18: sparse: sparse: incompatible types in comparison expression (different type sizes):
>> drivers/pwm/pwm-sifive.c:157:18: sparse: unsigned long long const *
>> drivers/pwm/pwm-sifive.c:157:18: sparse: unsigned int *
vim +157 drivers/pwm/pwm-sifive.c
129
130 static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
131 const struct pwm_state *state)
132 {
133 struct pwm_sifive_ddata *ddata = pwm_sifive_chip_to_ddata(chip);
134 struct pwm_state cur_state;
135 unsigned int duty_cycle, period;
136 unsigned long long num;
137 bool enabled;
138 int ret = 0;
139 u32 frac;
140
141 if (state->polarity != PWM_POLARITY_NORMAL && state->polarity != PWM_POLARITY_INVERSED)
142 return -EINVAL;
143
144 cur_state = pwm->state;
145 enabled = cur_state.enabled;
146
147 duty_cycle = state->duty_cycle;
148 if (!state->enabled)
149 duty_cycle = 0;
150
151 /*
152 * The problem of output producing mixed setting as mentioned at top,
153 * occurs here. To minimize the window for this problem, we are
154 * calculating the register values first and then writing them
155 * consecutively
156 */
> 157 period = max(state->period, ddata->approx_period);
158 num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH);
159 frac = DIV64_U64_ROUND_CLOSEST(num, state->period);
160 frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
161 /* The hardware cannot generate a 100% duty cycle */
162 frac = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - frac;
163
164
165 mutex_lock(&ddata->lock);
166 if (state->period != ddata->approx_period) {
167 /*
168 * Don't let a 2nd user change the period underneath the 1st user.
169 * However if ddate->approx_period == 0 this is the first time we set
170 * any period, so let whoever gets here first set the period so other
171 * users who agree on the period won't fail.
172 */
173 if (ddata->user_count != 1 && ddata->approx_period) {
174 mutex_unlock(&ddata->lock);
175 return -EBUSY;
176 }
177 ddata->approx_period = state->period;
178 pwm_sifive_update_clock(ddata, clk_get_rate(ddata->clk));
179 }
180 mutex_unlock(&ddata->lock);
181
182 /*
183 * If the PWM is enabled the clk is already on. So only enable it
184 * conditionally to have it on exactly once afterwards independent of
185 * the PWM state.
186 */
187 if (!enabled) {
188 ret = clk_enable(ddata->clk);
189 if (ret) {
190 dev_err(ddata->chip.dev, "Enable clk failed\n");
191 return ret;
192 }
193 }
194
195 writel(frac, ddata->regs + PWM_SIFIVE_PWMCMP(pwm->hwpwm));
196
197 if (!state->enabled)
198 clk_disable(ddata->clk);
199
200 return 0;
201 }
202
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Powered by blists - more mailing lists