Linux I2C development
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Peter Bohner <peter@bohner.me>,
	Wolfram Sang <wsa-dev@sang-engineering.com>,
	Jean Delvare <jdelvare@suse.com>,
	linux-i2c@vger.kernel.org
Cc: oe-kbuild-all@lists.linux.dev, Peter Bohner <peter@bohner.me>
Subject: Re: [PATCH] i2c: i2c-stub: support for I2C_FUNC_I2C
Date: Fri, 15 May 2026 14:53:28 +0200	[thread overview]
Message-ID: <202605151418.JKwPcs0v-lkp@intel.com> (raw)
In-Reply-To: <20260514081100.381043-1-peter@bohner.me>

Hi Peter,

kernel test robot noticed the following build errors:

[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on linus/master v6.16-rc1 next-20260508]
[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/Peter-Bohner/i2c-i2c-stub-support-for-I2C_FUNC_I2C/20260515-113705
base:   https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
patch link:    https://lore.kernel.org/r/20260514081100.381043-1-peter%40bohner.me
patch subject: [PATCH] i2c: i2c-stub: support for I2C_FUNC_I2C
config: x86_64-rhel-9.4 (https://download.01.org/0day-ci/archive/20260515/202605151418.JKwPcs0v-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260515/202605151418.JKwPcs0v-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@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605151418.JKwPcs0v-lkp@intel.com/

All errors (new ones prefixed by >>):

   drivers/i2c/i2c-stub.c: In function 'stub_xfer':
>> drivers/i2c/i2c-stub.c:157:33: error: implicit declaration of function 'krelloc_array'; did you mean 'krealloc_array'? [-Wimplicit-function-declaration]
     157 |                                 krelloc_array(chip->i2c_rw_data, msg->len, 1,
         |                                 ^~~~~~~~~~~~~
         |                                 krealloc_array
>> drivers/i2c/i2c-stub.c:156:36: error: assignment to 'u8 *' {aka 'unsigned char *'} from 'int' makes pointer from integer without a cast [-Wint-conversion]
     156 |                         new_rw_mem =
         |                                    ^


vim +157 drivers/i2c/i2c-stub.c

   140	
   141	static s32 stub_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
   142	{
   143		int i;
   144		u8 *new_rw_mem;
   145		struct stub_chip *chip = NULL;
   146		struct i2c_msg *msg;
   147	
   148		for (i = 0; i < num; i++) {
   149			msg = msgs + i;
   150			chip = stub_addr_to_chip(msg->addr);
   151			if (!chip)
   152				return -ENODEV;
   153	
   154			/* len is guaranteed to be <= 8192 by i2cdev_ioctl_rdwr */
   155			if (chip->i2c_rw_size < msg->len) {
 > 156				new_rw_mem =
 > 157					krelloc_array(chip->i2c_rw_data, msg->len, 1,
   158						      GFP_KERNEL | __GFP_ZERO);
   159				if (!new_rw_mem)
   160					return -ENOMEM;
   161				chip->i2c_rw_data = new_rw_mem;
   162				chip->i2c_rw_size = msg->len;
   163			}
   164	
   165			/* read, size determined by slave */
   166			if ((msg->flags & I2C_M_RD) && (msg->flags & I2C_M_RECV_LEN)) {
   167				/* i2cdev_ioctl_rdwr expects this as a maximum, even
   168				 * though 0xff would be the theoretically possible
   169				 */
   170				msg->len = min(chip->i2c_rw_size, I2C_SMBUS_BLOCK_MAX);
   171				msg->buf[0] = msg->len - 1;
   172				dev_dbg(&adap->dev,
   173					"i2c read with RECV_LEN - addr 0x%02x, read %u bytes\n",
   174					msg->addr, msg->len);
   175				memcpy(msg->buf + 1, chip->i2c_rw_data, msg->len - 1);
   176			} else if (msg->flags & I2C_M_RD) {
   177				dev_dbg(&adap->dev,
   178					"i2c read - addr 0x%02x, read %u bytes\n",
   179					msg->addr, msg->len);
   180				memcpy(msg->buf, chip->i2c_rw_data, msg->len);
   181			} else {
   182				dev_dbg(&adap->dev,
   183					"i2c write - addr 0x%02x, wrote %u bytes\n",
   184					msg->addr, msg->len);
   185				memcpy(chip->i2c_rw_data, msg->buf, msg->len);
   186			}
   187		}
   188		return num;
   189	}
   190	

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

  parent reply	other threads:[~2026-05-15 12:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-14  8:11 [PATCH] i2c: i2c-stub: support for I2C_FUNC_I2C Peter Bohner
2026-05-15  9:54 ` kernel test robot
2026-05-15 10:05 ` kernel test robot
2026-05-15 12:53 ` kernel test robot [this message]
2026-05-15 16:05 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202605151418.JKwPcs0v-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=jdelvare@suse.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=peter@bohner.me \
    --cc=wsa-dev@sang-engineering.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox