[PATCH] crypto: qcom-rng - Fix qcom_rng_of_match unused warning
by Herbert Xu
On Sun, Jul 24, 2022 at 08:12:39AM +0800, kernel test robot wrote:
>
> >> drivers/crypto/qcom-rng.c:190:34: warning: 'qcom_rng_of_match' defined but not used [-Wunused-const-variable=]
> 190 | static const struct of_device_id qcom_rng_of_match[] = {
> | ^~~~~~~~~~~~~~~~~
---8<---
Module device tables need to be declared as maybe_unused because
they will be unused when built-in and the corresponding option is
also disabled.
This patch adds the maybe_unused attributes to OF and ACPI. This
also allows us to remove the ifdef around the ACPI data structure.
Reported-by: kernel test robot <lkp(a)intel.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
diff --git a/drivers/crypto/qcom-rng.c b/drivers/crypto/qcom-rng.c
index 031b5f701a0a..72dd1a4ebac4 100644
--- a/drivers/crypto/qcom-rng.c
+++ b/drivers/crypto/qcom-rng.c
@@ -9,6 +9,7 @@
#include <linux/crypto.h>
#include <linux/io.h>
#include <linux/iopoll.h>
+#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
@@ -201,15 +202,13 @@ static int qcom_rng_remove(struct platform_device *pdev)
return 0;
}
-#if IS_ENABLED(CONFIG_ACPI)
-static const struct acpi_device_id qcom_rng_acpi_match[] = {
+static const struct acpi_device_id __maybe_unused qcom_rng_acpi_match[] = {
{ .id = "QCOM8160", .driver_data = 1 },
{}
};
MODULE_DEVICE_TABLE(acpi, qcom_rng_acpi_match);
-#endif
-static const struct of_device_id qcom_rng_of_match[] = {
+static const struct of_device_id __maybe_unused qcom_rng_of_match[] = {
{ .compatible = "qcom,prng", .data = (void *)0},
{ .compatible = "qcom,prng-ee", .data = (void *)1},
{}
--
Email: Herbert Xu <herbert(a)gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
2 weeks
Re: [RESEND 3/4 v7] power: supply: Add charger driver for Rockchip RK817
by Chris Morgan
On Sun, Jul 24, 2022 at 10:58:00PM +0800, kernel test robot wrote:
> Hi Chris,
>
> Thank you for the patch! Perhaps something to improve:
I'm afraid I'm not sure the best way to fix this. The only thing I can
think of is for now the driver should only be for systems with a
Rockchip RK817 PMIC (to my knowledge only ARM based systems from
Rockchip), but it looks like the arch was set as parisc. Even still,
as long as some of the functions ahead of it don't error out each
of those variables should be used. Is there a way to confirm these
warnings?
Thank you.
>
> [auto build test WARNING on lee-mfd/for-mfd-next]
> [also build test WARNING on sre-power-supply/for-next rockchip/for-next linus/master v5.19-rc7 next-20220722]
> [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/Chris-Morgan/power-supply-...
> base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
> config: parisc-allmodconfig (https://download.01.org/0day-ci/archive/20220724/202207242227.mttUkfTB-lk...)
> compiler: hppa-linux-gcc (GCC) 12.1.0
> 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/008e6f0d590e275cbb56d4506b5...
> git remote add linux-review https://github.com/intel-lab-lkp/linux
> git fetch --no-tags linux-review Chris-Morgan/power-supply-Add-Support-for-RK817-Charger/20220722-002431
> git checkout 008e6f0d590e275cbb56d4506b5638156506dd40
> # save the config file
> mkdir build_dir && cp config build_dir/.config
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=parisc SHELL=/bin/bash drivers/power/supply/
>
> If you fix the issue, kindly add following tag where applicable
> Reported-by: kernel test robot <lkp(a)intel.com>
>
> All warnings (new ones prefixed by >>):
>
> drivers/power/supply/rk817_charger.c: In function 'rk817_read_or_set_full_charge_on_boot':
> >> drivers/power/supply/rk817_charger.c:701:33: warning: variable 'soc_tmp3' set but not used [-Wunused-but-set-variable]
> 701 | int soc_tmp1, soc_tmp2, soc_tmp3;
> | ^~~~~~~~
> >> drivers/power/supply/rk817_charger.c:701:23: warning: variable 'soc_tmp2' set but not used [-Wunused-but-set-variable]
> 701 | int soc_tmp1, soc_tmp2, soc_tmp3;
> | ^~~~~~~~
> >> drivers/power/supply/rk817_charger.c:701:13: warning: variable 'soc_tmp1' set but not used [-Wunused-but-set-variable]
> 701 | int soc_tmp1, soc_tmp2, soc_tmp3;
> | ^~~~~~~~
>
>
> vim +/soc_tmp3 +701 drivers/power/supply/rk817_charger.c
>
> 692
> 693 static int
> 694 rk817_read_or_set_full_charge_on_boot(struct rk817_charger *charger,
> 695 struct power_supply_battery_info *bat_info)
> 696 {
> 697 struct rk808 *rk808 = charger->rk808;
> 698 u8 bulk_reg[4];
> 699 u32 boot_voltage, boot_charge_mah, tmp;
> 700 int ret, reg, off_time;
> > 701 int soc_tmp1, soc_tmp2, soc_tmp3;
> 702 bool first_boot;
> 703
> 704 /* Check if the battery is uninitalized. If it is, the columb counter
> 705 * needs to be set up.
> 706 */
> 707 ret = regmap_read(rk808->regmap, RK817_GAS_GAUGE_GG_STS, ®);
> 708 if (ret < 0)
> 709 return ret;
> 710 first_boot = reg & RK817_BAT_CON;
> 711 /* If the battery is uninitialized, use the poweron voltage and an ocv
> 712 * lookup to guess our charge. The number won't be very accurate until
> 713 * we hit either our minimum voltage (0%) or full charge (100%).
> 714 */
> 715 if (first_boot) {
> 716 regmap_bulk_read(rk808->regmap, RK817_GAS_GAUGE_PWRON_VOL_H,
> 717 bulk_reg, 2);
> 718 tmp = get_unaligned_be16(bulk_reg);
> 719 boot_voltage = (charger->voltage_k * tmp) +
> 720 1000 * charger->voltage_b;
> 721 /* Since only implementation has no working thermistor, assume
> 722 * 20C for OCV lookup. If lookup fails, report error with OCV
> 723 * table.
> 724 */
> 725 charger->soc = power_supply_batinfo_ocv2cap(bat_info,
> 726 boot_voltage,
> 727 20) * 1000;
> 728 if (charger->soc < 0)
> 729 charger->soc = 0;
> 730
> 731 /* Guess that full charge capacity is the design capacity */
> 732 charger->fcc_mah = charger->bat_charge_full_design_uah / 1000;
> 733 /* Set battery as "set up". BSP driver uses this value even
> 734 * though datasheet claims it's a read-only value.
> 735 */
> 736 regmap_write_bits(rk808->regmap, RK817_GAS_GAUGE_GG_STS,
> 737 RK817_BAT_CON, 0);
> 738 /* Save nvram values */
> 739 ret = rk817_record_battery_nvram_values(charger);
> 740 if (ret < 0)
> 741 return ret;
> 742 } else {
> 743 ret = rk817_read_battery_nvram_values(charger);
> 744 if (ret < 0)
> 745 return ret;
> 746
> 747 regmap_bulk_read(rk808->regmap, RK817_GAS_GAUGE_Q_PRES_H3,
> 748 bulk_reg, 4);
> 749 tmp = get_unaligned_be32(bulk_reg);
> 750 if (tmp < 0)
> 751 tmp = 0;
> 752 boot_charge_mah = ADC_TO_CHARGE_UAH(tmp,
> 753 charger->res_div) / 1000;
> 754 /* Check if the columb counter has been off for more than 300
> 755 * minutes as it tends to drift downward. If so, re-init soc
> 756 * with the boot voltage instead. Note the unit values for the
> 757 * OFF_CNT register appear to be in decaminutes and stops
> 758 * counting at 2550 (0xFF) minutes. BSP kernel used OCV, but
> 759 * for me occasionally that would show invalid values. Boot
> 760 * voltage is only accurate for me on first poweron (not
> 761 * reboots), but we shouldn't ever encounter an OFF_CNT more
> 762 * than 0 on a reboot anyway.
> 763 */
> 764 regmap_read(rk808->regmap, RK817_GAS_GAUGE_OFF_CNT, &off_time);
> 765 if (off_time >= 30) {
> 766 regmap_bulk_read(rk808->regmap,
> 767 RK817_GAS_GAUGE_PWRON_VOL_H,
> 768 bulk_reg, 2);
> 769 tmp = get_unaligned_be16(bulk_reg);
> 770 boot_voltage = (charger->voltage_k * tmp) +
> 771 1000 * charger->voltage_b;
> 772 charger->soc =
> 773 power_supply_batinfo_ocv2cap(bat_info,
> 774 boot_voltage,
> 775 20) * 1000;
> 776 } else {
> 777 charger->soc = (boot_charge_mah * 1000 * 100 /
> 778 charger->fcc_mah);
> 779 }
> 780 }
> 781
> 782 regmap_bulk_read(rk808->regmap, RK817_GAS_GAUGE_PWRON_VOL_H,
> 783 bulk_reg, 2);
> 784 tmp = get_unaligned_be16(bulk_reg);
> 785 boot_voltage = (charger->voltage_k * tmp) + 1000 * charger->voltage_b;
> 786 soc_tmp1 = power_supply_batinfo_ocv2cap(bat_info,
> 787 boot_voltage, 20) * 1000;
> 788 regmap_bulk_read(rk808->regmap, RK817_GAS_GAUGE_Q_PRES_H3,
> 789 bulk_reg, 4);
> 790 tmp = get_unaligned_be32(bulk_reg);
> 791 if (tmp < 0)
> 792 tmp = 0;
> 793 boot_charge_mah = ADC_TO_CHARGE_UAH(tmp, charger->res_div) / 1000;
> 794 soc_tmp2 = (boot_charge_mah * 1000 * 100 / charger->fcc_mah);
> 795 regmap_bulk_read(rk808->regmap, RK817_GAS_GAUGE_OCV_VOL_H,
> 796 bulk_reg, 2);
> 797 tmp = get_unaligned_be16(bulk_reg);
> 798 boot_voltage = (charger->voltage_k * tmp) + 1000 * charger->voltage_b;
> 799 soc_tmp3 = power_supply_batinfo_ocv2cap(bat_info,
> 800 boot_voltage, 20) * 1000;
> 801
> 802 /* Now we have our full charge capacity and soc, init the columb
> 803 * counter.
> 804 */
> 805 boot_charge_mah = charger->soc * charger->fcc_mah / 100 / 1000;
> 806 if (boot_charge_mah > charger->fcc_mah)
> 807 boot_charge_mah = charger->fcc_mah;
> 808 tmp = CHARGE_TO_ADC(boot_charge_mah, charger->res_div);
> 809 put_unaligned_be32(tmp, bulk_reg);
> 810 ret = regmap_bulk_write(rk808->regmap, RK817_GAS_GAUGE_Q_INIT_H3,
> 811 bulk_reg, 4);
> 812 if (ret < 0)
> 813 return ret;
> 814
> 815 /* Set QMAX value to max design capacity. */
> 816 tmp = CHARGE_TO_ADC((charger->bat_charge_full_design_uah / 1000),
> 817 charger->res_div);
> 818 put_unaligned_be32(tmp, bulk_reg);
> 819 ret = regmap_bulk_write(rk808->regmap, RK817_GAS_GAUGE_Q_MAX_H3,
> 820 bulk_reg, 4);
> 821 if (ret < 0)
> 822 return ret;
> 823
> 824 return 0;
> 825 }
> 826
>
> --
> 0-DAY CI Kernel Test Service
> https://01.org/lkp
2 weeks, 2 days
Re: [PATCH v4 6/7] media: i2c: ov9282: Set v4l2 subdev name according to sensor model
by Alexander Stein
Am Donnerstag, 28. Juli 2022, 23:10:07 CEST schrieb kernel test robot:
> Hi Alexander,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on media-tree/master]
> [also build test WARNING on linus/master v5.19-rc8 next-20220728]
> [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/Alexander-Stein/OV9281-suppo
> rt/20220728-210448 base: git://linuxtv.org/media_tree.git master
> config: arm-randconfig-r022-20220728
> (https://download.01.org/0day-ci/archive/20220729/202207290518.1D7MVS65-lkp
> @intel.com/config) compiler: clang version 15.0.0
> (https://github.com/llvm/llvm-project
> 8dfaecc4c24494337933aff9d9166486ca0949f1) 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
> # install arm cross compiling tool for clang build
> # apt-get install binutils-arm-linux-gnueabi
> #
> https://github.com/intel-lab-lkp/linux/commit/ee28006553d4d23f600b0076ef606
> 6710519f156 git remote add linux-review
> https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review
> Alexander-Stein/OV9281-support/20220728-210448 git checkout
> ee28006553d4d23f600b0076ef6066710519f156
> # 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=arm SHELL=/bin/bash drivers/media/i2c/
>
> If you fix the issue, kindly add following tag where applicable
> Reported-by: kernel test robot <lkp(a)intel.com>
>
> All warnings (new ones prefixed by >>):
> >> drivers/media/i2c/ov9282.c:1054:10: warning: variable 'ret' is
> >> uninitialized when used here [-Wuninitialized]
> return ret;
> ^~~
> drivers/media/i2c/ov9282.c:1041:9: note: initialize the variable 'ret' to
> silence this warning int ret;
> ^
> = 0
> 1 warning generated.
>
>
> vim +/ret +1054 drivers/media/i2c/ov9282.c
>
> 1030
> 1031 /**
> 1032 * ov9282_probe() - I2C client device binding
> 1033 * @client: pointer to i2c client device
> 1034 *
> 1035 * Return: 0 if successful, error code otherwise.
> 1036 */
> 1037 static int ov9282_probe(struct i2c_client *client)
> 1038 {
> 1039 struct ov9282 *ov9282;
> 1040 const char *sensor_name;
> 1041 int ret;
> 1042
> 1043 ov9282 = devm_kzalloc(&client->dev, sizeof(*ov9282),
GFP_KERNEL);
> 1044 if (!ov9282)
> 1045 return -ENOMEM;
> 1046
> 1047 ov9282->dev = &client->dev;
> 1048
> 1049 /* Initialize subdev */
> 1050 v4l2_i2c_subdev_init(&ov9282->sd, client,
&ov9282_subdev_ops);
> 1051 sensor_name = device_get_match_data(ov9282->dev);
> 1052 if (!sensor_name) {
> 1053 dev_err(ov9282->dev, "Sensor name is
missing");
>
> > 1054 return ret;
>
> 1055 }
> 1056 v4l2_i2c_subdev_set_name(&ov9282->sd, client,
sensor_name, NULL);
> 1057
> 1058 ret = ov9282_parse_hw_config(ov9282);
> 1059 if (ret) {
> 1060 dev_err(ov9282->dev, "HW configuration is not
supported");
> 1061 return ret;
> 1062 }
> 1063
> 1064 ret = ov9282_get_regulators(ov9282);
> 1065 if (ret) {
> 1066 dev_err(&client->dev, "Failed to get power
regulators\n");
> 1067 return ret;
> 1068 }
> 1069
> 1070 mutex_init(&ov9282->mutex);
> 1071
> 1072 ret = ov9282_power_on(ov9282->dev);
> 1073 if (ret) {
> 1074 dev_err(ov9282->dev, "failed to power-on the
sensor");
> 1075 goto error_mutex_destroy;
> 1076 }
> 1077
> 1078 /* Check module identity */
> 1079 ret = ov9282_detect(ov9282);
> 1080 if (ret) {
> 1081 dev_err(ov9282->dev, "failed to find sensor:
%d", ret);
> 1082 goto error_power_off;
> 1083 }
> 1084
> 1085 /* Set default mode to max resolution */
> 1086 ov9282->cur_mode = &supported_mode;
> 1087 ov9282->vblank = ov9282->cur_mode->vblank;
> 1088
> 1089 ret = ov9282_init_controls(ov9282);
> 1090 if (ret) {
> 1091 dev_err(ov9282->dev, "failed to init
controls: %d", ret);
> 1092 goto error_power_off;
> 1093 }
> 1094
> 1095 /* Initialize subdev */
> 1096 ov9282->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> 1097 ov9282->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
> 1098
> 1099 /* Initialize source pad */
> 1100 ov9282->pad.flags = MEDIA_PAD_FL_SOURCE;
> 1101 ret = media_entity_pads_init(&ov9282->sd.entity, 1,
&ov9282->pad);
> 1102 if (ret) {
> 1103 dev_err(ov9282->dev, "failed to init entity
pads: %d", ret);
> 1104 goto error_handler_free;
> 1105 }
> 1106
> 1107 ret = v4l2_async_register_subdev_sensor(&ov9282->sd);
> 1108 if (ret < 0) {
> 1109 dev_err(ov9282->dev,
> 1110 "failed to register async subdev:
%d", ret);
> 1111 goto error_media_entity;
> 1112 }
> 1113
> 1114 pm_runtime_set_active(ov9282->dev);
> 1115 pm_runtime_enable(ov9282->dev);
> 1116 pm_runtime_idle(ov9282->dev);
> 1117
> 1118 return 0;
> 1119
> 1120 error_media_entity:
> 1121 media_entity_cleanup(&ov9282->sd.entity);
> 1122 error_handler_free:
> 1123 v4l2_ctrl_handler_free(ov9282->sd.ctrl_handler);
> 1124 error_power_off:
> 1125 ov9282_power_off(ov9282->dev);
> 1126 error_mutex_destroy:
> 1127 mutex_destroy(&ov9282->mutex);
> 1128
> 1129 return ret;
> 1130 }
> 1131
Meh, I'll come up with a fixed once discussion about the additional compatible
has settled. This will also include the missing member documentation in patch
5
Best regards,
Alexander
2 weeks, 2 days
「VISAカード 」ご利用環境確認用ワンタイムURLのお知らせ
by VISA JAPAN
【VISAカード】利用いただき、ありがとうございます。
このたび、ご本人様のご利用かどうかを確認させていただきたいお取引がありましたので、誠に勝手ながら、カードのご利用を一部制限させていただき、ご連絡させていただきました。
つきましては、以下へアクセスの上、カードのご利用確認にご協力をお願い致します。
お客様にはご迷惑、ご心配をお掛けし、誠に申し訳ございません。
何卒ご理解いただきたくお願い申しあげます。
ご回答をいただけない場合、カードのご利用制限が継続されることもございますので、予めご了承下さい。
■ご利用確認はこちら
ご不便とご心配をおかけしまして誠に申し訳ございませんが、
何とぞご理解賜りたくお願い申しあげます。
──────────────────────────────────
■発行者■
VISAカード
東京都中野区中野4-3-2
──────────────────────────────────
©Copyright 1996-2022. All Rights Reserved.
無断転載および再配布を禁じます。
2 weeks, 2 days
VISAカード お支払い予定金額のご案内
by VISAカード
【VISAカード】利用いただき、ありがとうございます。
このたび、ご本人様のご利用かどうかを確認させていただきたいお取引がありましたので、誠に勝手ながら、カードのご利用を一部制限させていただき、ご連絡させていただきました。
つきましては、以下へアクセスの上、カードのご利用確認にご協力をお願い致します。
お客様にはご迷惑、ご心配をお掛けし、誠に申し訳ございません。
何卒ご理解いただきたくお願い申しあげます。
ご回答をいただけない場合、カードのご利用制限が継続されることもございますので、予めご了承下さい。
■ご利用確認はこちら
ご不便とご心配をおかけしまして誠に申し訳ございませんが、
何とぞご理解賜りたくお願い申しあげます。
──────────────────────────────────
■発行者■
VISAカード
東京都中野区中野4-3-2
──────────────────────────────────
©Copyright 1996-2022. All Rights Reserved.
無断転載および再配布を禁じます。
2 weeks, 3 days
VISAカード【重要:必ずお読みください】
by VISAカード
【VISAカード】利用いただき、ありがとうございます。
このたび、ご本人様のご利用かどうかを確認させていただきたいお取引がありましたので、誠に勝手ながら、カードのご利用を一部制限させていただき、ご連絡させていただきました。
つきましては、以下へアクセスの上、カードのご利用確認にご協力をお願い致します。
お客様にはご迷惑、ご心配をお掛けし、誠に申し訳ございません。
何卒ご理解いただきたくお願い申しあげます。
ご回答をいただけない場合、カードのご利用制限が継続されることもございますので、予めご了承下さい。
■ご利用確認はこちら
ご不便とご心配をおかけしまして誠に申し訳ございませんが、
何とぞご理解賜りたくお願い申しあげます。
──────────────────────────────────
■発行者■
VISAカード
東京都中野区中野4-3-2
──────────────────────────────────
©Copyright 1996-2022. All Rights Reserved.
無断転載および再配布を禁じます。
2 weeks, 3 days
[thermal:thermal/next 28/36] drivers/thermal/thermal_of.c:689:1-23: WARNING: Function "for_each_child_of_node" should have of_node_put() before goto around lines 692. (fwd)
by Julia Lawall
I didn't receive a code snippet with this message, but it may be worth
checkin whether there is a missing of_node_put.
julia
---------- Forwarded message ----------
Date: Sun, 31 Jul 2022 10:35:03 +0800
From: kernel test robot <lkp(a)intel.com>
To: kbuild(a)lists.01.org
Cc: lkp(a)intel.com, Julia Lawall <julia.lawall(a)lip6.fr>
Subject: [thermal:thermal/next 28/36] drivers/thermal/thermal_of.c:689:1-23:
WARNING: Function "for_each_child_of_node" should have of_node_put() before
goto around lines 692.
CC: kbuild-all(a)lists.01.org
BCC: lkp(a)intel.com
CC: linux-kernel(a)vger.kernel.org
TO: Daniel Lezcano <daniel.lezcano(a)linexp.org>
tree: git://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux.git thermal/next
head: d0c75fa2c17f082b32a5f26ff40bf378b12952de
commit: a3193edcbdf9a8ae73b6e1f2da96e920582c1849 [28/36] thermal/of: Replace device node match with device node search
:::::: branch date: 2 days ago
:::::: commit date: 2 days ago
config: nios2-randconfig-c033-20220729 (https://download.01.org/0day-ci/archive/20220731/202207311043.WDsouQI6-lk...)
compiler: nios2-linux-gcc (GCC) 12.1.0
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp(a)intel.com>
Reported-by: Julia Lawall <julia.lawall(a)lip6.fr>
cocci warnings: (new ones prefixed by >>)
>> drivers/thermal/thermal_of.c:689:1-23: WARNING: Function "for_each_child_of_node" should have of_node_put() before goto around lines 692.
--
0-DAY CI Kernel Test Service
https://01.org/lkp
2 weeks, 3 days
Re: [PATCH] i2c: Use u8 type in i2c transfer calls
by Jason Gerecke
On Tue, Jul 19, 2022 at 5:21 PM kernel test robot <rong.a.chen(a)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-t...
> 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-lk...)
> 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/9732240c23a365c0590f05ce831...
> 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(a)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?
2 weeks, 3 days