* Re: [PATCH] i2c: Use u8 type in i2c transfer calls
@ 2022-07-18 22:15 kernel test robot
2022-07-20 0:20 ` kernel test robot
0 siblings, 1 reply; 13+ messages in thread
From: kernel test robot @ 2022-07-18 22:15 UTC (permalink / raw)
To: kbuild
[-- Attachment #1: Type: text/plain, Size: 15337 bytes --]
::::::
:::::: Manual check reason: "commit no functional change"
::::::
CC: llvm(a)lists.linux.dev
CC: kbuild-all(a)lists.01.org
BCC: lkp(a)intel.com
In-Reply-To: <20220718153448.173652-1-jason.gerecke@wacom.com>
References: <20220718153448.173652-1-jason.gerecke@wacom.com>
TO: Jason Gerecke <killertofu@gmail.com>
TO: linux-i2c(a)vger.kernel.org
TO: Wolfram Sang <wsa-dev@sang-engineering.com>
CC: Ping Cheng <pinglinux@gmail.com>
CC: "Tobita, Tatsunosuke" <tatsunosuke.tobita@wacom.com>
CC: Jason Gerecke <jason.gerecke@wacom.com>
Hi Jason,
I love your patch! Yet something to improve:
[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on linus/master v5.19-rc7 next-20220718]
[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/Jason-Gerecke/i2c-Use-u8-type-in-i2c-transfer-calls/20220718-233658
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
:::::: branch date: 7 hours ago
:::::: commit date: 7 hours ago
config: hexagon-randconfig-r026-20220718 (https://download.01.org/0day-ci/archive/20220719/202207190634.ToyhlXSz-lkp(a)intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project d74b88c69dc2644bd0dc5d64e2d7413a0d4040e5)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/9732240c23a365c0590f05ce83196869235a2ea7
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Jason-Gerecke/i2c-Use-u8-type-in-i2c-transfer-calls/20220718-233658
git checkout 9732240c23a365c0590f05ce83196869235a2ea7
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/iio/adc/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/iio/adc/max1363.c:1645:12: error: incompatible function pointer types assigning to 'int (*)(const struct i2c_client *, const char *, int)' from 'int (const struct i2c_client *, const u8 *, int)' (aka 'int (const struct i2c_client *, const unsigned char *, int)') [-Werror,-Wincompatible-function-pointer-types]
st->send = i2c_master_send;
^ ~~~~~~~~~~~~~~~
>> drivers/iio/adc/max1363.c:1646:12: error: incompatible function pointer types assigning to 'int (*)(const struct i2c_client *, char *, int)' from 'int (const struct i2c_client *, u8 *, int)' (aka 'int (const struct i2c_client *, unsigned char *, int)') [-Werror,-Wincompatible-function-pointer-types]
st->recv = i2c_master_recv;
^ ~~~~~~~~~~~~~~~
2 errors generated.
vim +1645 drivers/iio/adc/max1363.c
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1584
fc52692c49969e drivers/iio/adc/max1363.c Greg Kroah-Hartman 2012-12-21 1585 static int max1363_probe(struct i2c_client *client,
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2009-08-18 1586 const struct i2c_device_id *id)
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2009-08-18 1587 {
cd4361c7e2e077 drivers/staging/iio/adc/max1363_core.c Michael Hennerich 2012-02-22 1588 int ret;
3dba81ba803ca0 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-04-15 1589 struct max1363_state *st;
3dba81ba803ca0 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-04-15 1590 struct iio_dev *indio_dev;
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck 2013-02-03 1591 struct regulator *vref;
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2009-08-18 1592
6917e1d9af2c50 drivers/iio/adc/max1363.c Sachin Kamat 2013-07-22 1593 indio_dev = devm_iio_device_alloc(&client->dev,
6917e1d9af2c50 drivers/iio/adc/max1363.c Sachin Kamat 2013-07-22 1594 sizeof(struct max1363_state));
6917e1d9af2c50 drivers/iio/adc/max1363.c Sachin Kamat 2013-07-22 1595 if (!indio_dev)
6917e1d9af2c50 drivers/iio/adc/max1363.c Sachin Kamat 2013-07-22 1596 return -ENOMEM;
b77b8f8c20c83c drivers/staging/iio/adc/max1363.c Jonathan Cameron 2012-10-06 1597
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1598 ret = devm_iio_map_array_register(&client->dev, indio_dev,
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1599 client->dev.platform_data);
0b27d678c7fbeb drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2012-04-10 1600 if (ret < 0)
6917e1d9af2c50 drivers/iio/adc/max1363.c Sachin Kamat 2013-07-22 1601 return ret;
b77b8f8c20c83c drivers/staging/iio/adc/max1363.c Jonathan Cameron 2012-10-06 1602
3dba81ba803ca0 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-04-15 1603 st = iio_priv(indio_dev);
b77b8f8c20c83c drivers/staging/iio/adc/max1363.c Jonathan Cameron 2012-10-06 1604
bf09cddb2cd402 drivers/iio/adc/max1363.c Rohit Sarkar 2020-03-15 1605 mutex_init(&st->lock);
7c3e8675f37503 drivers/iio/adc/max1363.c Guenter Roeck 2013-02-03 1606 st->reg = devm_regulator_get(&client->dev, "vcc");
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1607 if (IS_ERR(st->reg))
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1608 return PTR_ERR(st->reg);
b77b8f8c20c83c drivers/staging/iio/adc/max1363.c Jonathan Cameron 2012-10-06 1609
b77b8f8c20c83c drivers/staging/iio/adc/max1363.c Jonathan Cameron 2012-10-06 1610 ret = regulator_enable(st->reg);
b77b8f8c20c83c drivers/staging/iio/adc/max1363.c Jonathan Cameron 2012-10-06 1611 if (ret)
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1612 return ret;
b77b8f8c20c83c drivers/staging/iio/adc/max1363.c Jonathan Cameron 2012-10-06 1613
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1614 ret = devm_add_action_or_reset(&client->dev, max1363_reg_disable, st->reg);
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1615 if (ret)
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1616 return ret;
3dba81ba803ca0 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-04-15 1617
f84ff467c0ce5b drivers/iio/adc/max1363.c Jonathan Cameron 2020-06-28 1618 st->chip_info = device_get_match_data(&client->dev);
794ac821cc44e4 drivers/iio/adc/max1363.c Julia Lawall 2018-05-21 1619 if (!st->chip_info)
3dba81ba803ca0 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-04-15 1620 st->chip_info = &max1363_chip_info_tbl[id->driver_data];
3dba81ba803ca0 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-04-15 1621 st->client = client;
3dba81ba803ca0 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-04-15 1622
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck 2013-02-03 1623 st->vref_uv = st->chip_info->int_vref_mv * 1000;
55b40d37311807 drivers/iio/adc/max1363.c Guenter Roeck 2014-01-27 1624 vref = devm_regulator_get_optional(&client->dev, "vref");
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck 2013-02-03 1625 if (!IS_ERR(vref)) {
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck 2013-02-03 1626 int vref_uv;
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck 2013-02-03 1627
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck 2013-02-03 1628 ret = regulator_enable(vref);
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck 2013-02-03 1629 if (ret)
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1630 return ret;
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1631
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1632 ret = devm_add_action_or_reset(&client->dev, max1363_reg_disable, vref);
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1633 if (ret)
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1634 return ret;
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1635
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck 2013-02-03 1636 st->vref = vref;
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck 2013-02-03 1637 vref_uv = regulator_get_voltage(vref);
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1638 if (vref_uv <= 0)
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1639 return -EINVAL;
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1640
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck 2013-02-03 1641 st->vref_uv = vref_uv;
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck 2013-02-03 1642 }
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck 2013-02-03 1643
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot 2013-10-20 1644 if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot 2013-10-20 @1645 st->send = i2c_master_send;
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot 2013-10-20 @1646 st->recv = i2c_master_recv;
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot 2013-10-20 1647 } else if (i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE)
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot 2013-10-20 1648 && st->chip_info->bits == 8) {
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot 2013-10-20 1649 st->send = max1363_smbus_send;
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot 2013-10-20 1650 st->recv = max1363_smbus_recv;
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot 2013-10-20 1651 } else {
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1652 return -EOPNOTSUPP;
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot 2013-10-20 1653 }
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot 2013-10-20 1654
cd4361c7e2e077 drivers/staging/iio/adc/max1363_core.c Michael Hennerich 2012-02-22 1655 ret = max1363_alloc_scan_masks(indio_dev);
cd4361c7e2e077 drivers/staging/iio/adc/max1363_core.c Michael Hennerich 2012-02-22 1656 if (ret)
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1657 return ret;
82020b0ef15de0 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2010-05-04 1658
845bd12ac78f92 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-05-18 1659 indio_dev->name = id->name;
8e7d967244a8ee drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-08-30 1660 indio_dev->channels = st->chip_info->channels;
8e7d967244a8ee drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-08-30 1661 indio_dev->num_channels = st->chip_info->num_channels;
6fe8135fccd66a drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-05-18 1662 indio_dev->info = st->chip_info->info;
6fe8135fccd66a drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-05-18 1663 indio_dev->modes = INDIO_DIRECT_MODE;
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2009-08-18 1664 ret = max1363_initial_setup(st);
58f0a255454dc2 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-05-18 1665 if (ret < 0)
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1666 return ret;
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2009-08-18 1667
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1668 ret = devm_iio_triggered_buffer_setup(&client->dev, indio_dev, NULL,
7a1aeba7ed0d5a drivers/iio/adc/max1363.c Lars-Peter Clausen 2013-09-16 1669 &max1363_trigger_handler, NULL);
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2009-08-18 1670 if (ret)
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1671 return ret;
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2009-08-18 1672
6fe8135fccd66a drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-05-18 1673 if (client->irq) {
7c3e8675f37503 drivers/iio/adc/max1363.c Guenter Roeck 2013-02-03 1674 ret = devm_request_threaded_irq(&client->dev, st->client->irq,
aaf370db7dad57 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-05-18 1675 NULL,
aaf370db7dad57 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-05-18 1676 &max1363_event_handler,
aaf370db7dad57 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-05-18 1677 IRQF_TRIGGER_RISING | IRQF_ONESHOT,
aaf370db7dad57 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-05-18 1678 "max1363_event",
aaf370db7dad57 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-05-18 1679 indio_dev);
298cd976e07f1a drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-05-18 1680
440a5200347734 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2010-06-26 1681 if (ret)
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2009-08-18 1682 return ret;
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2009-08-18 1683 }
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2009-08-18 1684
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean 2021-09-26 1685 return devm_iio_device_register(&client->dev, indio_dev);
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2009-08-18 1686 }
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2009-08-18 1687
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH] i2c: Use u8 type in i2c transfer calls
2022-07-18 22:15 [PATCH] i2c: Use u8 type in i2c transfer calls kernel test robot
@ 2022-07-20 0:20 ` kernel test robot
2022-07-20 19:01 ` Jason Gerecke
0 siblings, 1 reply; 13+ messages in thread
From: kernel test robot @ 2022-07-20 0:20 UTC (permalink / raw)
To: Jason Gerecke, linux-i2c, Wolfram Sang
Cc: Ping Cheng, Tobita, Tatsunosuke, Jason Gerecke, llvm, kbuild-all
Hi Jason,
I love your patch! Yet something to improve:
[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on linus/master v5.19-rc7 next-20220718]
[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/Jason-Gerecke/i2c-Use-u8-type-in-i2c-transfer-calls/20220718-233658
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
i2c/for-next
config: hexagon-randconfig-r026-20220718
(https://download.01.org/0day-ci/archive/20220719/202207190634.ToyhlXSz-lkp@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
d74b88c69dc2644bd0dc5d64e2d7413a0d4040e5)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/9732240c23a365c0590f05ce83196869235a2ea7
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Jason-Gerecke/i2c-Use-u8-type-in-i2c-transfer-calls/20220718-233658
git checkout 9732240c23a365c0590f05ce83196869235a2ea7
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/iio/adc/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/iio/adc/max1363.c:1645:12: error: incompatible function pointer types assigning to 'int (*)(const struct i2c_client *, const char *, int)' from 'int (const struct i2c_client *, const u8 *, int)' (aka 'int (const struct i2c_client *, const unsigned char *, int)') [-Werror,-Wincompatible-function-pointer-types]
st->send = i2c_master_send;
^ ~~~~~~~~~~~~~~~
>> drivers/iio/adc/max1363.c:1646:12: error: incompatible function pointer types assigning to 'int (*)(const struct i2c_client *, char *, int)' from 'int (const struct i2c_client *, u8 *, int)' (aka 'int (const struct i2c_client *, unsigned char *, int)') [-Werror,-Wincompatible-function-pointer-types]
st->recv = i2c_master_recv;
^ ~~~~~~~~~~~~~~~
2 errors generated.
vim +1645 drivers/iio/adc/max1363.c
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1584 fc52692c49969e drivers/iio/adc/max1363.c
Greg Kroah-Hartman 2012-12-21 1585 static int max1363_probe(struct
i2c_client *client,
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2009-08-18 1586 const struct i2c_device_id *id)
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2009-08-18 1587 {
cd4361c7e2e077 drivers/staging/iio/adc/max1363_core.c Michael Hennerich
2012-02-22 1588 int ret;
3dba81ba803ca0 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-04-15 1589 struct max1363_state *st;
3dba81ba803ca0 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-04-15 1590 struct iio_dev *indio_dev;
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck
2013-02-03 1591 struct regulator *vref;
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2009-08-18 1592 6917e1d9af2c50 drivers/iio/adc/max1363.c
Sachin Kamat 2013-07-22 1593 indio_dev =
devm_iio_device_alloc(&client->dev,
6917e1d9af2c50 drivers/iio/adc/max1363.c Sachin Kamat
2013-07-22 1594 sizeof(struct max1363_state));
6917e1d9af2c50 drivers/iio/adc/max1363.c Sachin Kamat
2013-07-22 1595 if (!indio_dev)
6917e1d9af2c50 drivers/iio/adc/max1363.c Sachin Kamat
2013-07-22 1596 return -ENOMEM;
b77b8f8c20c83c drivers/staging/iio/adc/max1363.c Jonathan Cameron
2012-10-06 1597 a1ff6d25261315 drivers/iio/adc/max1363.c
Alexandru Ardelean 2021-09-26 1598 ret =
devm_iio_map_array_register(&client->dev, indio_dev,
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1599 client->dev.platform_data);
0b27d678c7fbeb drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2012-04-10 1600 if (ret < 0)
6917e1d9af2c50 drivers/iio/adc/max1363.c Sachin Kamat
2013-07-22 1601 return ret;
b77b8f8c20c83c drivers/staging/iio/adc/max1363.c Jonathan Cameron
2012-10-06 1602 3dba81ba803ca0
drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-04-15
1603 st = iio_priv(indio_dev);
b77b8f8c20c83c drivers/staging/iio/adc/max1363.c Jonathan Cameron
2012-10-06 1604 bf09cddb2cd402 drivers/iio/adc/max1363.c
Rohit Sarkar 2020-03-15 1605 mutex_init(&st->lock);
7c3e8675f37503 drivers/iio/adc/max1363.c Guenter Roeck
2013-02-03 1606 st->reg = devm_regulator_get(&client->dev, "vcc");
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1607 if (IS_ERR(st->reg))
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1608 return PTR_ERR(st->reg);
b77b8f8c20c83c drivers/staging/iio/adc/max1363.c Jonathan Cameron
2012-10-06 1609 b77b8f8c20c83c drivers/staging/iio/adc/max1363.c
Jonathan Cameron 2012-10-06 1610 ret = regulator_enable(st->reg);
b77b8f8c20c83c drivers/staging/iio/adc/max1363.c Jonathan Cameron
2012-10-06 1611 if (ret)
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1612 return ret;
b77b8f8c20c83c drivers/staging/iio/adc/max1363.c Jonathan Cameron
2012-10-06 1613 a1ff6d25261315 drivers/iio/adc/max1363.c
Alexandru Ardelean 2021-09-26 1614 ret =
devm_add_action_or_reset(&client->dev, max1363_reg_disable, st->reg);
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1615 if (ret)
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1616 return ret;
3dba81ba803ca0 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-04-15 1617 f84ff467c0ce5b drivers/iio/adc/max1363.c
Jonathan Cameron 2020-06-28 1618 st->chip_info =
device_get_match_data(&client->dev);
794ac821cc44e4 drivers/iio/adc/max1363.c Julia Lawall
2018-05-21 1619 if (!st->chip_info)
3dba81ba803ca0 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-04-15 1620 st->chip_info =
&max1363_chip_info_tbl[id->driver_data];
3dba81ba803ca0 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-04-15 1621 st->client = client;
3dba81ba803ca0 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-04-15 1622 a405b00e4470b1 drivers/iio/adc/max1363.c
Guenter Roeck 2013-02-03 1623 st->vref_uv =
st->chip_info->int_vref_mv * 1000;
55b40d37311807 drivers/iio/adc/max1363.c Guenter Roeck
2014-01-27 1624 vref = devm_regulator_get_optional(&client->dev,
"vref");
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck
2013-02-03 1625 if (!IS_ERR(vref)) {
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck
2013-02-03 1626 int vref_uv;
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck
2013-02-03 1627 a405b00e4470b1 drivers/iio/adc/max1363.c
Guenter Roeck 2013-02-03 1628 ret = regulator_enable(vref);
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck
2013-02-03 1629 if (ret)
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1630 return ret;
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1631 a1ff6d25261315 drivers/iio/adc/max1363.c
Alexandru Ardelean 2021-09-26 1632 ret =
devm_add_action_or_reset(&client->dev, max1363_reg_disable, vref);
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1633 if (ret)
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1634 return ret;
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1635 a405b00e4470b1 drivers/iio/adc/max1363.c
Guenter Roeck 2013-02-03 1636 st->vref = vref;
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck
2013-02-03 1637 vref_uv = regulator_get_voltage(vref);
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1638 if (vref_uv <= 0)
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1639 return -EINVAL;
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1640 a405b00e4470b1 drivers/iio/adc/max1363.c
Guenter Roeck 2013-02-03 1641 st->vref_uv = vref_uv;
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck
2013-02-03 1642 }
a405b00e4470b1 drivers/iio/adc/max1363.c Guenter Roeck
2013-02-03 1643 61bdda69222c09 drivers/iio/adc/max1363.c
Vivien Didelot 2013-10-20 1644 if
(i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot
2013-10-20 @1645 st->send = i2c_master_send;
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot
2013-10-20 @1646 st->recv = i2c_master_recv;
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot
2013-10-20 1647 } else if (i2c_check_functionality(client->adapter,
I2C_FUNC_SMBUS_BYTE)
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot
2013-10-20 1648 && st->chip_info->bits == 8) {
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot
2013-10-20 1649 st->send = max1363_smbus_send;
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot
2013-10-20 1650 st->recv = max1363_smbus_recv;
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot
2013-10-20 1651 } else {
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1652 return -EOPNOTSUPP;
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot
2013-10-20 1653 }
61bdda69222c09 drivers/iio/adc/max1363.c Vivien Didelot
2013-10-20 1654 cd4361c7e2e077
drivers/staging/iio/adc/max1363_core.c Michael Hennerich 2012-02-22
1655 ret = max1363_alloc_scan_masks(indio_dev);
cd4361c7e2e077 drivers/staging/iio/adc/max1363_core.c Michael Hennerich
2012-02-22 1656 if (ret)
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1657 return ret;
82020b0ef15de0 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2010-05-04 1658 845bd12ac78f92
drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-05-18
1659 indio_dev->name = id->name;
8e7d967244a8ee drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-08-30 1660 indio_dev->channels = st->chip_info->channels;
8e7d967244a8ee drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-08-30 1661 indio_dev->num_channels = st->chip_info->num_channels;
6fe8135fccd66a drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-05-18 1662 indio_dev->info = st->chip_info->info;
6fe8135fccd66a drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-05-18 1663 indio_dev->modes = INDIO_DIRECT_MODE;
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2009-08-18 1664 ret = max1363_initial_setup(st);
58f0a255454dc2 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-05-18 1665 if (ret < 0)
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1666 return ret;
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2009-08-18 1667 a1ff6d25261315 drivers/iio/adc/max1363.c
Alexandru Ardelean 2021-09-26 1668 ret =
devm_iio_triggered_buffer_setup(&client->dev, indio_dev, NULL,
7a1aeba7ed0d5a drivers/iio/adc/max1363.c Lars-Peter Clausen
2013-09-16 1669 &max1363_trigger_handler, NULL);
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2009-08-18 1670 if (ret)
a1ff6d25261315 drivers/iio/adc/max1363.c Alexandru Ardelean
2021-09-26 1671 return ret;
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2009-08-18 1672 6fe8135fccd66a
drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2011-05-18
1673 if (client->irq) {
7c3e8675f37503 drivers/iio/adc/max1363.c Guenter Roeck
2013-02-03 1674 ret = devm_request_threaded_irq(&client->dev,
st->client->irq,
aaf370db7dad57 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-05-18 1675 NULL,
aaf370db7dad57 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-05-18 1676 &max1363_event_handler,
aaf370db7dad57 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-05-18 1677 IRQF_TRIGGER_RISING | IRQF_ONESHOT,
aaf370db7dad57 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-05-18 1678 "max1363_event",
aaf370db7dad57 drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-05-18 1679 indio_dev);
298cd976e07f1a drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2011-05-18 1680 440a5200347734
drivers/staging/iio/adc/max1363_core.c Jonathan Cameron 2010-06-26
1681 if (ret)
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2009-08-18 1682 return ret;
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2009-08-18 1683 }
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2009-08-18 1684 a1ff6d25261315 drivers/iio/adc/max1363.c
Alexandru Ardelean 2021-09-26 1685 return
devm_iio_device_register(&client->dev, indio_dev);
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2009-08-18 1686 }
d1325cf45077bd drivers/staging/iio/adc/max1363_core.c Jonathan Cameron
2009-08-18 1687
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH] i2c: Use u8 type in i2c transfer calls
2022-07-20 0:20 ` kernel test robot
@ 2022-07-20 19:01 ` Jason Gerecke
0 siblings, 0 replies; 13+ messages in thread
From: Jason Gerecke @ 2022-07-20 19:01 UTC (permalink / raw)
To: Jonathan Cameron, Lars-Peter Clausen, Wolfram Sang
Cc: linux-i2c, Ping Cheng, Tobita, Tatsunosuke, Jason Gerecke, llvm,
kbuild-all, linux-iio, LKML
On Tue, Jul 19, 2022 at 5:21 PM kernel test robot <rong.a.chen@intel.com> wrote:
>
>
> Hi Jason,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on wsa/i2c/for-next]
> [also build test ERROR on linus/master v5.19-rc7 next-20220718]
> [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/Jason-Gerecke/i2c-Use-u8-type-in-i2c-transfer-calls/20220718-233658
> base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
> i2c/for-next
> config: hexagon-randconfig-r026-20220718
> (https://download.01.org/0day-ci/archive/20220719/202207190634.ToyhlXSz-lkp@intel.com/config)
> compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
> d74b88c69dc2644bd0dc5d64e2d7413a0d4040e5)
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
> -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> #
> https://github.com/intel-lab-lkp/linux/commit/9732240c23a365c0590f05ce83196869235a2ea7
> git remote add linux-review https://github.com/intel-lab-lkp/linux
> git fetch --no-tags linux-review
> Jason-Gerecke/i2c-Use-u8-type-in-i2c-transfer-calls/20220718-233658
> git checkout 9732240c23a365c0590f05ce83196869235a2ea7
> # save the config file
> mkdir build_dir && cp config build_dir/.config
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
> O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/iio/adc/
>
> If you fix the issue, kindly add following tag where applicable
> Reported-by: kernel test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> >> drivers/iio/adc/max1363.c:1645:12: error: incompatible function pointer types assigning to 'int (*)(const struct i2c_client *, const char *, int)' from 'int (const struct i2c_client *, const u8 *, int)' (aka 'int (const struct i2c_client *, const unsigned char *, int)') [-Werror,-Wincompatible-function-pointer-types]
> st->send = i2c_master_send;
> ^ ~~~~~~~~~~~~~~~
> >> drivers/iio/adc/max1363.c:1646:12: error: incompatible function pointer types assigning to 'int (*)(const struct i2c_client *, char *, int)' from 'int (const struct i2c_client *, u8 *, int)' (aka 'int (const struct i2c_client *, unsigned char *, int)') [-Werror,-Wincompatible-function-pointer-types]
> st->recv = i2c_master_recv;
> ^ ~~~~~~~~~~~~~~~
> 2 errors generated.
Wolfram and Jonathan,
Writing a patch to fix the new warnings generated by my I2C patch is
simple enough, but I'd like some help coordinating getting both
patches landed. Should I wait for the I2C patch to land in "for-next"
before sending the IIO fix, or would it be preferred to send the IIO
fix right now so that both patches can be reviewed simultaneously?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] i2c: Use u8 type in i2c transfer calls
@ 2022-07-20 19:01 ` Jason Gerecke
0 siblings, 0 replies; 13+ messages in thread
From: Jason Gerecke @ 2022-07-20 19:01 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 3147 bytes --]
On Tue, Jul 19, 2022 at 5:21 PM kernel test robot <rong.a.chen@intel.com> wrote:
>
>
> Hi Jason,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on wsa/i2c/for-next]
> [also build test ERROR on linus/master v5.19-rc7 next-20220718]
> [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/Jason-Gerecke/i2c-Use-u8-type-in-i2c-transfer-calls/20220718-233658
> base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
> i2c/for-next
> config: hexagon-randconfig-r026-20220718
> (https://download.01.org/0day-ci/archive/20220719/202207190634.ToyhlXSz-lkp(a)intel.com/config)
> compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
> d74b88c69dc2644bd0dc5d64e2d7413a0d4040e5)
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
> -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> #
> https://github.com/intel-lab-lkp/linux/commit/9732240c23a365c0590f05ce83196869235a2ea7
> git remote add linux-review https://github.com/intel-lab-lkp/linux
> git fetch --no-tags linux-review
> Jason-Gerecke/i2c-Use-u8-type-in-i2c-transfer-calls/20220718-233658
> git checkout 9732240c23a365c0590f05ce83196869235a2ea7
> # save the config file
> mkdir build_dir && cp config build_dir/.config
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
> O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/iio/adc/
>
> If you fix the issue, kindly add following tag where applicable
> Reported-by: kernel test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> >> drivers/iio/adc/max1363.c:1645:12: error: incompatible function pointer types assigning to 'int (*)(const struct i2c_client *, const char *, int)' from 'int (const struct i2c_client *, const u8 *, int)' (aka 'int (const struct i2c_client *, const unsigned char *, int)') [-Werror,-Wincompatible-function-pointer-types]
> st->send = i2c_master_send;
> ^ ~~~~~~~~~~~~~~~
> >> drivers/iio/adc/max1363.c:1646:12: error: incompatible function pointer types assigning to 'int (*)(const struct i2c_client *, char *, int)' from 'int (const struct i2c_client *, u8 *, int)' (aka 'int (const struct i2c_client *, unsigned char *, int)') [-Werror,-Wincompatible-function-pointer-types]
> st->recv = i2c_master_recv;
> ^ ~~~~~~~~~~~~~~~
> 2 errors generated.
Wolfram and Jonathan,
Writing a patch to fix the new warnings generated by my I2C patch is
simple enough, but I'd like some help coordinating getting both
patches landed. Should I wait for the I2C patch to land in "for-next"
before sending the IIO fix, or would it be preferred to send the IIO
fix right now so that both patches can be reviewed simultaneously?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] i2c: Use u8 type in i2c transfer calls
2022-07-20 19:01 ` Jason Gerecke
@ 2022-07-28 14:26 ` Jason Gerecke
-1 siblings, 0 replies; 13+ messages in thread
From: Jason Gerecke @ 2022-07-28 14:26 UTC (permalink / raw)
To: Jonathan Cameron, Lars-Peter Clausen, Wolfram Sang
Cc: linux-i2c, Ping Cheng, Tobita, Tatsunosuke, Jason Gerecke, llvm,
kbuild-all, linux-iio, LKML
On Wed, Jul 20, 2022 at 12:01 PM Jason Gerecke <killertofu@gmail.com> wrote:
>
> On Tue, Jul 19, 2022 at 5:21 PM kernel test robot <rong.a.chen@intel.com> wrote:
> >
> >
> > Hi Jason,
> >
> > I love your patch! Yet something to improve:
> >
> > [auto build test ERROR on wsa/i2c/for-next]
> > [also build test ERROR on linus/master v5.19-rc7 next-20220718]
> > [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/Jason-Gerecke/i2c-Use-u8-type-in-i2c-transfer-calls/20220718-233658
> > base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
> > i2c/for-next
> > config: hexagon-randconfig-r026-20220718
> > (https://download.01.org/0day-ci/archive/20220719/202207190634.ToyhlXSz-lkp@intel.com/config)
> > compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
> > d74b88c69dc2644bd0dc5d64e2d7413a0d4040e5)
> > reproduce (this is a W=1 build):
> > wget
> > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
> > -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > #
> > https://github.com/intel-lab-lkp/linux/commit/9732240c23a365c0590f05ce83196869235a2ea7
> > git remote add linux-review https://github.com/intel-lab-lkp/linux
> > git fetch --no-tags linux-review
> > Jason-Gerecke/i2c-Use-u8-type-in-i2c-transfer-calls/20220718-233658
> > git checkout 9732240c23a365c0590f05ce83196869235a2ea7
> > # save the config file
> > mkdir build_dir && cp config build_dir/.config
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
> > O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/iio/adc/
> >
> > If you fix the issue, kindly add following tag where applicable
> > Reported-by: kernel test robot <lkp@intel.com>
> >
> > All errors (new ones prefixed by >>):
> >
> > >> drivers/iio/adc/max1363.c:1645:12: error: incompatible function pointer types assigning to 'int (*)(const struct i2c_client *, const char *, int)' from 'int (const struct i2c_client *, const u8 *, int)' (aka 'int (const struct i2c_client *, const unsigned char *, int)') [-Werror,-Wincompatible-function-pointer-types]
> > st->send = i2c_master_send;
> > ^ ~~~~~~~~~~~~~~~
> > >> drivers/iio/adc/max1363.c:1646:12: error: incompatible function pointer types assigning to 'int (*)(const struct i2c_client *, char *, int)' from 'int (const struct i2c_client *, u8 *, int)' (aka 'int (const struct i2c_client *, unsigned char *, int)') [-Werror,-Wincompatible-function-pointer-types]
> > st->recv = i2c_master_recv;
> > ^ ~~~~~~~~~~~~~~~
> > 2 errors generated.
>
> Wolfram and Jonathan,
>
> Writing a patch to fix the new warnings generated by my I2C patch is
> simple enough, but I'd like some help coordinating getting both
> patches landed. Should I wait for the I2C patch to land in "for-next"
> before sending the IIO fix, or would it be preferred to send the IIO
> fix right now so that both patches can be reviewed simultaneously?
It's been pretty quiet, so asking again for any thoughts on how to
best address this tangle...
Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] i2c: Use u8 type in i2c transfer calls
@ 2022-07-28 14:26 ` Jason Gerecke
0 siblings, 0 replies; 13+ messages in thread
From: Jason Gerecke @ 2022-07-28 14:26 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 3448 bytes --]
On Wed, Jul 20, 2022 at 12:01 PM Jason Gerecke <killertofu@gmail.com> wrote:
>
> On Tue, Jul 19, 2022 at 5:21 PM kernel test robot <rong.a.chen@intel.com> wrote:
> >
> >
> > Hi Jason,
> >
> > I love your patch! Yet something to improve:
> >
> > [auto build test ERROR on wsa/i2c/for-next]
> > [also build test ERROR on linus/master v5.19-rc7 next-20220718]
> > [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/Jason-Gerecke/i2c-Use-u8-type-in-i2c-transfer-calls/20220718-233658
> > base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
> > i2c/for-next
> > config: hexagon-randconfig-r026-20220718
> > (https://download.01.org/0day-ci/archive/20220719/202207190634.ToyhlXSz-lkp(a)intel.com/config)
> > compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
> > d74b88c69dc2644bd0dc5d64e2d7413a0d4040e5)
> > reproduce (this is a W=1 build):
> > wget
> > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
> > -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > #
> > https://github.com/intel-lab-lkp/linux/commit/9732240c23a365c0590f05ce83196869235a2ea7
> > git remote add linux-review https://github.com/intel-lab-lkp/linux
> > git fetch --no-tags linux-review
> > Jason-Gerecke/i2c-Use-u8-type-in-i2c-transfer-calls/20220718-233658
> > git checkout 9732240c23a365c0590f05ce83196869235a2ea7
> > # save the config file
> > mkdir build_dir && cp config build_dir/.config
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
> > O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/iio/adc/
> >
> > If you fix the issue, kindly add following tag where applicable
> > Reported-by: kernel test robot <lkp@intel.com>
> >
> > All errors (new ones prefixed by >>):
> >
> > >> drivers/iio/adc/max1363.c:1645:12: error: incompatible function pointer types assigning to 'int (*)(const struct i2c_client *, const char *, int)' from 'int (const struct i2c_client *, const u8 *, int)' (aka 'int (const struct i2c_client *, const unsigned char *, int)') [-Werror,-Wincompatible-function-pointer-types]
> > st->send = i2c_master_send;
> > ^ ~~~~~~~~~~~~~~~
> > >> drivers/iio/adc/max1363.c:1646:12: error: incompatible function pointer types assigning to 'int (*)(const struct i2c_client *, char *, int)' from 'int (const struct i2c_client *, u8 *, int)' (aka 'int (const struct i2c_client *, unsigned char *, int)') [-Werror,-Wincompatible-function-pointer-types]
> > st->recv = i2c_master_recv;
> > ^ ~~~~~~~~~~~~~~~
> > 2 errors generated.
>
> Wolfram and Jonathan,
>
> Writing a patch to fix the new warnings generated by my I2C patch is
> simple enough, but I'd like some help coordinating getting both
> patches landed. Should I wait for the I2C patch to land in "for-next"
> before sending the IIO fix, or would it be preferred to send the IIO
> fix right now so that both patches can be reviewed simultaneously?
It's been pretty quiet, so asking again for any thoughts on how to
best address this tangle...
Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] i2c: Use u8 type in i2c transfer calls
2022-07-28 14:26 ` Jason Gerecke
@ 2022-07-28 20:47 ` Andy Shevchenko
-1 siblings, 0 replies; 13+ messages in thread
From: Andy Shevchenko @ 2022-07-28 20:47 UTC (permalink / raw)
To: Jason Gerecke
Cc: Jonathan Cameron, Lars-Peter Clausen, Wolfram Sang, linux-i2c,
Ping Cheng, Tobita, Tatsunosuke, Jason Gerecke, llvm, kbuild-all,
linux-iio, LKML
On Thu, Jul 28, 2022 at 4:30 PM Jason Gerecke <killertofu@gmail.com> wrote:
> On Wed, Jul 20, 2022 at 12:01 PM Jason Gerecke <killertofu@gmail.com> wrote:
> > On Tue, Jul 19, 2022 at 5:21 PM kernel test robot <rong.a.chen@intel.com> wrote:
> > Writing a patch to fix the new warnings generated by my I2C patch is
> > simple enough, but I'd like some help coordinating getting both
> > patches landed. Should I wait for the I2C patch to land in "for-next"
> > before sending the IIO fix, or would it be preferred to send the IIO
> > fix right now so that both patches can be reviewed simultaneously?
>
> It's been pretty quiet, so asking again for any thoughts on how to
> best address this tangle...
The rule of thumb is not to introduce an additional warning or compile error.
I haven't looked deeply into this case, but it smells to me as if you need a new
version of your initial patch that includes a fix to IIO.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] i2c: Use u8 type in i2c transfer calls
@ 2022-07-28 20:47 ` Andy Shevchenko
0 siblings, 0 replies; 13+ messages in thread
From: Andy Shevchenko @ 2022-07-28 20:47 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 979 bytes --]
On Thu, Jul 28, 2022 at 4:30 PM Jason Gerecke <killertofu@gmail.com> wrote:
> On Wed, Jul 20, 2022 at 12:01 PM Jason Gerecke <killertofu@gmail.com> wrote:
> > On Tue, Jul 19, 2022 at 5:21 PM kernel test robot <rong.a.chen@intel.com> wrote:
> > Writing a patch to fix the new warnings generated by my I2C patch is
> > simple enough, but I'd like some help coordinating getting both
> > patches landed. Should I wait for the I2C patch to land in "for-next"
> > before sending the IIO fix, or would it be preferred to send the IIO
> > fix right now so that both patches can be reviewed simultaneously?
>
> It's been pretty quiet, so asking again for any thoughts on how to
> best address this tangle...
The rule of thumb is not to introduce an additional warning or compile error.
I haven't looked deeply into this case, but it smells to me as if you need a new
version of your initial patch that includes a fix to IIO.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] i2c: Use u8 type in i2c transfer calls
2022-07-28 20:47 ` Andy Shevchenko
@ 2022-07-28 22:48 ` Jason Gerecke
-1 siblings, 0 replies; 13+ messages in thread
From: Jason Gerecke @ 2022-07-28 22:48 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, Lars-Peter Clausen, Wolfram Sang, linux-i2c,
Ping Cheng, Tobita, Tatsunosuke, Jason Gerecke, llvm, kbuild-all,
linux-iio, LKML
On Thu, Jul 28, 2022 at 1:48 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Thu, Jul 28, 2022 at 4:30 PM Jason Gerecke <killertofu@gmail.com> wrote:
> > On Wed, Jul 20, 2022 at 12:01 PM Jason Gerecke <killertofu@gmail.com> wrote:
> > > On Tue, Jul 19, 2022 at 5:21 PM kernel test robot <rong.a.chen@intel.com> wrote:
>
> > > Writing a patch to fix the new warnings generated by my I2C patch is
> > > simple enough, but I'd like some help coordinating getting both
> > > patches landed. Should I wait for the I2C patch to land in "for-next"
> > > before sending the IIO fix, or would it be preferred to send the IIO
> > > fix right now so that both patches can be reviewed simultaneously?
> >
> > It's been pretty quiet, so asking again for any thoughts on how to
> > best address this tangle...
>
> The rule of thumb is not to introduce an additional warning or compile error.
> I haven't looked deeply into this case, but it smells to me as if you need a new
> version of your initial patch that includes a fix to IIO.
>
>
> --
> With Best Regards,
> Andy Shevchenko
Thanks! Since the patch would touch both IIO and I2C I assume I would
submit it to both mailinglists. And that whichever maintainer gets to
it first would just give their Reviewed-by (if all looks good) and the
second applies the Signed-off-by and handles the merge?
I'll work on the updated combined patch...
Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] i2c: Use u8 type in i2c transfer calls
@ 2022-07-28 22:48 ` Jason Gerecke
0 siblings, 0 replies; 13+ messages in thread
From: Jason Gerecke @ 2022-07-28 22:48 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]
On Thu, Jul 28, 2022 at 1:48 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Thu, Jul 28, 2022 at 4:30 PM Jason Gerecke <killertofu@gmail.com> wrote:
> > On Wed, Jul 20, 2022 at 12:01 PM Jason Gerecke <killertofu@gmail.com> wrote:
> > > On Tue, Jul 19, 2022 at 5:21 PM kernel test robot <rong.a.chen@intel.com> wrote:
>
> > > Writing a patch to fix the new warnings generated by my I2C patch is
> > > simple enough, but I'd like some help coordinating getting both
> > > patches landed. Should I wait for the I2C patch to land in "for-next"
> > > before sending the IIO fix, or would it be preferred to send the IIO
> > > fix right now so that both patches can be reviewed simultaneously?
> >
> > It's been pretty quiet, so asking again for any thoughts on how to
> > best address this tangle...
>
> The rule of thumb is not to introduce an additional warning or compile error.
> I haven't looked deeply into this case, but it smells to me as if you need a new
> version of your initial patch that includes a fix to IIO.
>
>
> --
> With Best Regards,
> Andy Shevchenko
Thanks! Since the patch would touch both IIO and I2C I assume I would
submit it to both mailinglists. And that whichever maintainer gets to
it first would just give their Reviewed-by (if all looks good) and the
second applies the Signed-off-by and handles the merge?
I'll work on the updated combined patch...
Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] i2c: Use u8 type in i2c transfer calls
2022-07-28 22:48 ` Jason Gerecke
@ 2022-07-31 12:43 ` Jonathan Cameron
-1 siblings, 0 replies; 13+ messages in thread
From: Jonathan Cameron @ 2022-07-31 12:43 UTC (permalink / raw)
To: Jason Gerecke
Cc: Andy Shevchenko, Lars-Peter Clausen, Wolfram Sang, linux-i2c,
Ping Cheng, Tobita, Tatsunosuke, Jason Gerecke, llvm, kbuild-all,
linux-iio, LKML
On Thu, 28 Jul 2022 15:48:59 -0700
Jason Gerecke <killertofu@gmail.com> wrote:
> On Thu, Jul 28, 2022 at 1:48 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> >
> > On Thu, Jul 28, 2022 at 4:30 PM Jason Gerecke <killertofu@gmail.com> wrote:
> > > On Wed, Jul 20, 2022 at 12:01 PM Jason Gerecke <killertofu@gmail.com> wrote:
> > > > On Tue, Jul 19, 2022 at 5:21 PM kernel test robot <rong.a.chen@intel.com> wrote:
> >
> > > > Writing a patch to fix the new warnings generated by my I2C patch is
> > > > simple enough, but I'd like some help coordinating getting both
> > > > patches landed. Should I wait for the I2C patch to land in "for-next"
> > > > before sending the IIO fix, or would it be preferred to send the IIO
> > > > fix right now so that both patches can be reviewed simultaneously?
> > >
> > > It's been pretty quiet, so asking again for any thoughts on how to
> > > best address this tangle...
> >
> > The rule of thumb is not to introduce an additional warning or compile error.
> > I haven't looked deeply into this case, but it smells to me as if you need a new
> > version of your initial patch that includes a fix to IIO.
> >
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
>
> Thanks! Since the patch would touch both IIO and I2C I assume I would
> submit it to both mailinglists. And that whichever maintainer gets to
> it first would just give their Reviewed-by (if all looks good) and the
> second applies the Signed-off-by and handles the merge?
>
> I'll work on the updated combined patch...
I suspect this will be likely to create merge conflicts, so submit it like
that and I'll probably ask Wolfram to do an immutable branch that I can
then pull into IIO. Hence we'll have exactly the same commits (IDs and all)
in both IIO and I2C trees.
Jonathan
>
> Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] i2c: Use u8 type in i2c transfer calls
@ 2022-07-31 12:43 ` Jonathan Cameron
0 siblings, 0 replies; 13+ messages in thread
From: Jonathan Cameron @ 2022-07-31 12:43 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]
On Thu, 28 Jul 2022 15:48:59 -0700
Jason Gerecke <killertofu@gmail.com> wrote:
> On Thu, Jul 28, 2022 at 1:48 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> >
> > On Thu, Jul 28, 2022 at 4:30 PM Jason Gerecke <killertofu@gmail.com> wrote:
> > > On Wed, Jul 20, 2022 at 12:01 PM Jason Gerecke <killertofu@gmail.com> wrote:
> > > > On Tue, Jul 19, 2022 at 5:21 PM kernel test robot <rong.a.chen@intel.com> wrote:
> >
> > > > Writing a patch to fix the new warnings generated by my I2C patch is
> > > > simple enough, but I'd like some help coordinating getting both
> > > > patches landed. Should I wait for the I2C patch to land in "for-next"
> > > > before sending the IIO fix, or would it be preferred to send the IIO
> > > > fix right now so that both patches can be reviewed simultaneously?
> > >
> > > It's been pretty quiet, so asking again for any thoughts on how to
> > > best address this tangle...
> >
> > The rule of thumb is not to introduce an additional warning or compile error.
> > I haven't looked deeply into this case, but it smells to me as if you need a new
> > version of your initial patch that includes a fix to IIO.
> >
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
>
> Thanks! Since the patch would touch both IIO and I2C I assume I would
> submit it to both mailinglists. And that whichever maintainer gets to
> it first would just give their Reviewed-by (if all looks good) and the
> second applies the Signed-off-by and handles the merge?
>
> I'll work on the updated combined patch...
I suspect this will be likely to create merge conflicts, so submit it like
that and I'll probably ask Wolfram to do an immutable branch that I can
then pull into IIO. Hence we'll have exactly the same commits (IDs and all)
in both IIO and I2C trees.
Jonathan
>
> Jason
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] i2c: Use u8 type in i2c transfer calls
@ 2022-07-18 15:34 Jason Gerecke
0 siblings, 0 replies; 13+ messages in thread
From: Jason Gerecke @ 2022-07-18 15:34 UTC (permalink / raw)
To: linux-i2c, Wolfram Sang
Cc: Ping Cheng, Tobita, Tatsunosuke, Jason Gerecke, Ping Cheng
The 'i2c_transfer_buffer_flags' function (and related inlines) defines its
'buf' argument to be of type 'char*'. This is a poor choice of type given
that most callers actually pass a 'u8*' and that the function itself ends
up just storing the variable to a 'u8*'-typed member of 'struct i2c_msg'
anyway.
Changing the type of the 'buf' argument to 'u8*' vastly reduces the number
of (admittedly usually-silent) Wpointer-sign warnings that are generated
as the types get needlessly juggled back and forth.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
---
drivers/i2c/i2c-core-base.c | 2 +-
include/linux/i2c.h | 14 +++++++-------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 10f35f942066..2925507e8626 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -2184,7 +2184,7 @@ EXPORT_SYMBOL(i2c_transfer);
*
* Returns negative errno, or else the number of bytes transferred.
*/
-int i2c_transfer_buffer_flags(const struct i2c_client *client, char *buf,
+int i2c_transfer_buffer_flags(const struct i2c_client *client, u8 *buf,
int count, u16 flags)
{
int ret;
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index fbda5ada2afc..65c46df51c51 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -64,7 +64,7 @@ const char *i2c_freq_mode_string(u32 bus_freq_hz);
* @count must be less than 64k since msg.len is u16.
*/
int i2c_transfer_buffer_flags(const struct i2c_client *client,
- char *buf, int count, u16 flags);
+ u8 *buf, int count, u16 flags);
/**
* i2c_master_recv - issue a single I2C message in master receive mode
@@ -75,7 +75,7 @@ int i2c_transfer_buffer_flags(const struct i2c_client *client,
* Returns negative errno, or else the number of bytes read.
*/
static inline int i2c_master_recv(const struct i2c_client *client,
- char *buf, int count)
+ u8 *buf, int count)
{
return i2c_transfer_buffer_flags(client, buf, count, I2C_M_RD);
};
@@ -90,7 +90,7 @@ static inline int i2c_master_recv(const struct i2c_client *client,
* Returns negative errno, or else the number of bytes read.
*/
static inline int i2c_master_recv_dmasafe(const struct i2c_client *client,
- char *buf, int count)
+ u8 *buf, int count)
{
return i2c_transfer_buffer_flags(client, buf, count,
I2C_M_RD | I2C_M_DMA_SAFE);
@@ -105,9 +105,9 @@ static inline int i2c_master_recv_dmasafe(const struct i2c_client *client,
* Returns negative errno, or else the number of bytes written.
*/
static inline int i2c_master_send(const struct i2c_client *client,
- const char *buf, int count)
+ const u8 *buf, int count)
{
- return i2c_transfer_buffer_flags(client, (char *)buf, count, 0);
+ return i2c_transfer_buffer_flags(client, (u8 *)buf, count, 0);
};
/**
@@ -120,9 +120,9 @@ static inline int i2c_master_send(const struct i2c_client *client,
* Returns negative errno, or else the number of bytes written.
*/
static inline int i2c_master_send_dmasafe(const struct i2c_client *client,
- const char *buf, int count)
+ const u8 *buf, int count)
{
- return i2c_transfer_buffer_flags(client, (char *)buf, count,
+ return i2c_transfer_buffer_flags(client, (u8 *)buf, count,
I2C_M_DMA_SAFE);
};
--
2.37.1
^ permalink raw reply related [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-07-31 12:43 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-18 22:15 [PATCH] i2c: Use u8 type in i2c transfer calls kernel test robot
2022-07-20 0:20 ` kernel test robot
2022-07-20 19:01 ` Jason Gerecke
2022-07-20 19:01 ` Jason Gerecke
2022-07-28 14:26 ` Jason Gerecke
2022-07-28 14:26 ` Jason Gerecke
2022-07-28 20:47 ` Andy Shevchenko
2022-07-28 20:47 ` Andy Shevchenko
2022-07-28 22:48 ` Jason Gerecke
2022-07-28 22:48 ` Jason Gerecke
2022-07-31 12:43 ` Jonathan Cameron
2022-07-31 12:43 ` Jonathan Cameron
-- strict thread matches above, loose matches on Subject: below --
2022-07-18 15:34 Jason Gerecke
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.