[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202408030016.QLOhRHF1-lkp@intel.com>
Date: Sat, 3 Aug 2024 01:16:52 +0800
From: kernel test robot <lkp@...el.com>
To: Heiko Stuebner <heiko@...ech.de>, lee@...nel.org, jdelvare@...e.com,
linux@...ck-us.net, dmitry.torokhov@...il.com, pavel@....cz
Cc: oe-kbuild-all@...ts.linux.dev, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, heiko@...ech.de, ukleinek@...ian.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-rockchip@...ts.infradead.org, linux-hwmon@...r.kernel.org,
linux-input@...r.kernel.org, linux-leds@...r.kernel.org
Subject: Re: [PATCH v3 2/7] mfd: add base driver for qnap-mcu devices
Hi Heiko,
kernel test robot noticed the following build warnings:
[auto build test WARNING on next-20240801]
[also build test WARNING on v6.11-rc1]
[cannot apply to groeck-staging/hwmon-next lee-leds/for-leds-next lee-mfd/for-mfd-next lee-mfd/for-mfd-fixes linus/master v6.11-rc1 v6.10 v6.10-rc7]
[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/Heiko-Stuebner/dt-bindings-mfd-add-binding-for-qnap-ts433-mcu-devices/20240802-103948
base: next-20240801
patch link: https://lore.kernel.org/r/20240731212430.2677900-3-heiko%40sntech.de
patch subject: [PATCH v3 2/7] mfd: add base driver for qnap-mcu devices
config: sh-allmodconfig (https://download.01.org/0day-ci/archive/20240803/202408030016.QLOhRHF1-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 14.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240803/202408030016.QLOhRHF1-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@...el.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202408030016.QLOhRHF1-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from include/linux/device.h:15,
from include/linux/platform_device.h:13,
from include/linux/mfd/core.h:13,
from drivers/mfd/qnap-mcu.c:12:
drivers/mfd/qnap-mcu.c: In function 'qnap_mcu_receive_buf':
>> drivers/mfd/qnap-mcu.c:108:31: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'size_t' {aka 'unsigned int'} [-Wformat=]
108 | dev_warn(dev, "received %lu bytes, we were not waiting for\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/dev_printk.h:110:30: note: in definition of macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ^~~
include/linux/dev_printk.h:156:61: note: in expansion of macro 'dev_fmt'
156 | dev_printk_index_wrap(_dev_warn, KERN_WARNING, dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~
drivers/mfd/qnap-mcu.c:108:17: note: in expansion of macro 'dev_warn'
108 | dev_warn(dev, "received %lu bytes, we were not waiting for\n",
| ^~~~~~~~
drivers/mfd/qnap-mcu.c:108:43: note: format string is defined here
108 | dev_warn(dev, "received %lu bytes, we were not waiting for\n",
| ~~^
| |
| long unsigned int
| %u
vim +108 drivers/mfd/qnap-mcu.c
96
97 static size_t qnap_mcu_receive_buf(struct serdev_device *serdev,
98 const u8 *buf, size_t size)
99 {
100 struct device *dev = &serdev->dev;
101 struct qnap_mcu *mcu = dev_get_drvdata(dev);
102 struct qnap_mcu_reply *reply = mcu->reply;
103 const u8 *src = buf;
104 const u8 *end = buf + size;
105
106 mutex_lock(&mcu->reply_lock);
107 if (!reply) {
> 108 dev_warn(dev, "received %lu bytes, we were not waiting for\n",
109 size);
110 mutex_unlock(&mcu->reply_lock);
111 return size;
112 }
113
114 while (src < end) {
115 reply->data[reply->received] = *src++;
116 reply->received++;
117
118 if (reply->received == reply->length) {
119 complete(&reply->done);
120 mutex_unlock(&mcu->reply_lock);
121
122 /*
123 * We report the consumed number of bytes. If there
124 * are still bytes remaining (though there shouldn't)
125 * the serdev layer will re-execute this handler with
126 * the remainder of the Rx bytes.
127 */
128 return src - buf;
129 }
130 }
131
132 /*
133 * The only way to get out of the above loop and end up here
134 * is through consuming all of the supplied data, so here we
135 * report that we processed it all.
136 */
137 mutex_unlock(&mcu->reply_lock);
138 return size;
139 }
140
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Powered by blists - more mailing lists