Hi Krzysztof,
On Wed, 5 Jun 2024 12:33:11, krzk@xxxxxxxxxx wrote:
>On 05/06/2024 11:11, wangshuaijie@xxxxxxxxxx wrote:
>> From: shuaijie wang <wangshuaijie@xxxxxxxxxx>
>>
>> Signed-off-by: shuaijie wang <wangshuaijie@xxxxxxxxxx>
>> | Reported-by: kernel test robot <lkp@xxxxxxxxx>
>> | Reported-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
>> | Reported-by: Dan Carpenter <error27@xxxxxxxxx>
>> ---
>> drivers/input/misc/Kconfig | 9 +
>> drivers/input/misc/Makefile | 1 +
>> drivers/input/misc/aw_sar/Makefile | 2 +
>> drivers/input/misc/aw_sar/aw_sar.c | 2036 ++++++++++++++++++++++++++++
>> drivers/input/misc/aw_sar/aw_sar.h | 15 +
>> 5 files changed, 2063 insertions(+)
>> create mode 100644 drivers/input/misc/aw_sar/Makefile
>> create mode 100644 drivers/input/misc/aw_sar/aw_sar.c
>> create mode 100644 drivers/input/misc/aw_sar/aw_sar.h
>>
>> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
>> index 6ba984d7f0b1..ac56fdd21839 100644
>> --- a/drivers/input/misc/Kconfig
>> +++ b/drivers/input/misc/Kconfig
>> @@ -939,4 +939,13 @@ config INPUT_STPMIC1_ONKEY
>> To compile this driver as a module, choose M here: the
>> module will be called stpmic1_onkey.
>>
>> +config AWINIC_SAR
>> + tristate "Awinic sar sensor support"
>> + depends on I2C
>> + help
>> + Say Y to enable support for the Awinic sar sensor driver.
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called awinic_sar.
>> +
>> endif
>> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
>> index 04296a4abe8e..6ee1870ea677 100644
>> --- a/drivers/input/misc/Makefile
>> +++ b/drivers/input/misc/Makefile
>> @@ -90,3 +90,4 @@ obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
>> obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND) += xen-kbdfront.o
>> obj-$(CONFIG_INPUT_YEALINK) += yealink.o
>> obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR) += ideapad_slidebar.o
>> +obj-$(CONFIG_AWINIC_SAR) += aw_sar/
>> diff --git a/drivers/input/misc/aw_sar/Makefile b/drivers/input/misc/aw_sar/Makefile
>> new file mode 100644
>> index 000000000000..c357ecaa4f98
>> --- /dev/null
>> +++ b/drivers/input/misc/aw_sar/Makefile
>> @@ -0,0 +1,2 @@
>> +obj-$(CONFIG_AWINIC_SAR) += awinic_sar.o
>> +awinic_sar-objs := ./comm/aw_sar_comm_interface.o aw_sar.o ./aw9610x/aw9610x.o ./aw963xx/aw963xx.o
>> diff --git a/drivers/input/misc/aw_sar/aw_sar.c b/drivers/input/misc/aw_sar/aw_sar.c
>> new file mode 100644
>> index 000000000000..ab89fed65a6a
>> --- /dev/null
>> +++ b/drivers/input/misc/aw_sar/aw_sar.c
>> @@ -0,0 +1,2036 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * AWINIC sar sensor driver
>> + *
>> + * Author: Shuaijie Wang<wangshuaijie@xxxxxxxxxx>
>> + *
>> + * Copyright (c) 2024 awinic Technology CO., LTD
>> + */
>> +#include "./comm/aw_sar_chip_interface.h"
>> +#include "aw_sar.h"
>> +
>> +#define AW_SAR_I2C_NAME "awinic_sar"
>> +
>> +/*
>> + * Please check which power_supply on your platform
>> + * can get the charger insertion information, then select it.
>> + * eg: "usb"/"charger"/"mtk-master-charger"/"mtk_charger_type"
>> + */
>> +#define USB_POWER_SUPPLY_NAME "charger"
>> +/*
>> + * Check which of your power_supply properties is available
>> + * for the charger insertion information and select it.
>> + * eg: POWER_SUPPLY_PROP_ONLINE/POWER_SUPPLY_PROP_PRESENT
>> + */
>> +#define AW_USB_PROP_ONLINE POWER_SUPPLY_PROP_ONLINE
>> +
>> +#define AW_I2C_RW_RETRY_TIME_MIN (2000)
>> +#define AW_I2C_RW_RETRY_TIME_MAX (3000)
>> +#define AW_RETRIES (5)
>> +
>> +#define AW_SAR_AWRW_OffSET (20)
>> +#define AW_SAR_AWRW_DATA_WIDTH (5)
>> +#define AW_DATA_OffSET_2 (2)
>> +#define AW_DATA_OffSET_3 (3)
>> +#define AW_POWER_ON_SYSFS_DELAY_MS (5000)
>> +#define AW_SAR_MONITOR_ESD_DELAY_MS (5000)
>> +#define AW_SAR_OFFSET_LEN (15)
>> +#define AW_SAR_VCC_MIN_UV (1700000)
>> +#define AW_SAR_VCC_MAX_UV (3600000)
>> +
>> +static struct mutex aw_sar_lock;
>> +
>> +static int32_t aw_sar_get_chip_info(struct aw_sar *p_sar);
>> +static void aw_sar_sensor_free(struct aw_sar *p_sar);
>> +
>> +//Because disable/enable_irq api Therefore, IRQ is embedded
>> +void aw_sar_disable_irq(struct aw_sar *p_sar)
>> +{
>> + if (p_sar->irq_init.host_irq_stat == IRQ_ENABLE) {
>> + disable_irq(p_sar->irq_init.to_irq);
>> + p_sar->irq_init.host_irq_stat = IRQ_DISABLE;
>> + }
>> +}
>> +
>> +void aw_sar_enable_irq(struct aw_sar *p_sar)
>> +{
>> + if (p_sar->irq_init.host_irq_stat == IRQ_DISABLE) {
>> + enable_irq(p_sar->irq_init.to_irq);
>> + p_sar->irq_init.host_irq_stat = IRQ_ENABLE;
>> + }
>> +}
>> +
>> +//Chip logic part start
>> +//Load default array function
>> +static int32_t
>> +aw_sar_para_loaded_func(struct i2c_client *i2c, const struct aw_sar_para_load_t *para_load)
>> +{
>> + int32_t ret;
>> + int32_t i;
>
>int32_t? So you send user-space driver to the kernel? That would explain
>this terrible coding style, but it is a clear no-go.
>
The patch for v3 will fix these issues.
>
>...
>
>> +static void aw_sar_monitor_work(struct work_struct *aw_work)
>> +{
>> + struct aw_sar *p_sar = container_of(aw_work, struct aw_sar, monitor_work.work);
>> + uint32_t data;
>> + int32_t ret;
>> +
>> + ret = aw_sar_i2c_read(p_sar->i2c, 0x0000, &data);
>> + if (ret != 0) {
>> + dev_err(p_sar->dev, "read 0x0000 err: %d", ret);
>> + return;
>> + }
>> + if (data == 0 && p_sar->driver_code_initover_flag) {
>> + dev_err(p_sar->dev, "aw_chip may reset");
>> + aw_sar_disable_irq(p_sar);
>> + ret = aw_sar_chip_init(p_sar);
>> + if (ret != 0)
>> + return;
>> + }
>> + queue_delayed_work(p_sar->monitor_wq, &p_sar->monitor_work,
>> + msecs_to_jiffies(AW_SAR_MONITOR_ESD_DELAY_MS));
>> +}
>> +
>> +static int32_t aw_sar_monitor_esd_init(struct aw_sar *p_sar)
>> +{
>> + p_sar->monitor_wq = create_singlethread_workqueue("aw_sar_workqueue");
>> + if (!p_sar->monitor_wq) {
>> + dev_err(&p_sar->i2c->dev, "aw_sar_workqueue error");
>> + return -EINVAL;
>> + }
>> + INIT_DELAYED_WORK(&p_sar->monitor_work, aw_sar_monitor_work);
>> + queue_delayed_work(p_sar->monitor_wq, &p_sar->monitor_work,
>> + msecs_to_jiffies(AW_SAR_MONITOR_ESD_DELAY_MS));
>> +
>> + return 0;
>> +}
>> +
>> +static void aw_sar_sensor_free(struct aw_sar *p_sar)
>> +{
>> + if (g_aw_sar_driver_list[p_sar->curr_use_driver_type].p_chip_deinit != NULL)
>> + g_aw_sar_driver_list[p_sar->curr_use_driver_type].p_chip_deinit(p_sar);
>> +}
>> +
>> +
>> +/* Drive logic entry */
>> +static int32_t aw_sar_i2c_probe(struct i2c_client *i2c)
>> +{
>> + struct aw_sar *p_sar;
>> + int32_t ret;
>> +
>> + if (!i2c_check_functionality(i2c->adapter, I2C_FUNC_I2C)) {
>> + pr_err("check_functionality failed!\n");
>> + return -EIO;
>> + }
>> +
>> + p_sar = devm_kzalloc(&i2c->dev, sizeof(struct aw_sar), GFP_KERNEL);
>
>Heh, so you upstream 10 year old code?
>
>sizeof(*)
>
The patch for v3 will fix these issues.
>> + if (!p_sar) {
>> + ret = -ENOMEM;
>> + goto err_malloc;
>
>That's just return.
>
The patch for v3 will fix these issues.
>> + }
>> +
>> + p_sar->dev = &i2c->dev;
>> + p_sar->i2c = i2c;
>> + i2c_set_clientdata(i2c, p_sar);
>> +
>> + //1.Judge whether to use regular power supply. If yes, supply power
>> + ret = aw_sar_regulator_power(p_sar);
>> + if (ret != 0) {
>> + dev_err(&i2c->dev, "regulator_power error!");
>> + goto err_malloc;
>> + }
>> +
>> + //2.Get chip initialization resources
>> + ret = aw_sar_get_chip_info(p_sar);
>> + if (ret != 0) {
>> + dev_err(&i2c->dev, "chip_init error!");
>
>DON't SCREAM! No need!
>
The patch for v3 will fix these issues.
>> + goto err_chip_init;
>> + }
>> +
>> + //3.Chip initialization process
>> + ret = aw_sar_init(p_sar);
>> + if (ret != 0) {
>> + dev_err(&i2c->dev, "sar_init error!");
>> + goto err_sar_init;
>> + }
>> +
>> + if (p_sar->dts_info.monitor_esd_flag) {
>> + ret = aw_sar_monitor_esd_init(p_sar);
>> + if (ret != 0) {
>> + dev_err(&i2c->dev, "monitor_esd_init error!");
>> + goto err_esd_init;
>> + }
>> + }
>> +
>> + dev_dbg(&i2c->dev, "probe success!");
>
>No. Drop all silly function entry/exit/success messages.
>
>EVERYWHERE.
>
The patch for v3 will fix these issues.
>> +
>> + return 0;
>> +
>
>
>> +static const struct of_device_id aw_sar_dt_match[] = {
>> + { .compatible = "awinic,aw96103" },
>> + { .compatible = "awinic,aw96105" },
>> + { .compatible = "awinic,aw96303" },
>> + { .compatible = "awinic,aw96305" },
>> + { .compatible = "awinic,aw96308" },
>
>So all are compatible... express it in bindings.
>
Yes, all of them are compatible.
>> + { },
>> +};
>> +
>> +static const struct i2c_device_id aw_sar_i2c_id[] = {
>> + { AW_SAR_I2C_NAME, 0 },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(i2c, aw_sar_i2c_id);
>> +
>> +static struct i2c_driver aw_sar_i2c_driver = {
>> + .driver = {
>> + .name = AW_SAR_I2C_NAME,
>> + .owner = THIS_MODULE,
>
>NAK
>
The patch for v3 will fix these issues.
>> + .of_match_table = aw_sar_dt_match,
>> + .pm = &aw_sar_pm_ops,
>> + },
>> + .probe = aw_sar_i2c_probe,
>> + .remove = aw_sar_i2c_remove,
>> + .shutdown = aw_sar_i2c_shutdown,
>> + .id_table = aw_sar_i2c_id,
>> +};
>> +
>> +static int32_t __init aw_sar_i2c_init(void)
>> +{
>> + int32_t ret;
>> +
>> + ret = i2c_add_driver(&aw_sar_i2c_driver);
>> + if (ret) {
>> + pr_err("fail to add aw_sar device into i2c\n");
>> + return ret;
>> + }
>
>Srsly, this is just NAK. This code is way too poor. Get some internal
>help from awinic, because this should not be sent.
>
The patch for v3 will fix these issues.
>> +
>> + return 0;
>> +}
>> +
>> +module_init(aw_sar_i2c_init);
>> +static void __exit aw_sar_i2c_exit(void)
>> +{
>> + i2c_del_driver(&aw_sar_i2c_driver);
>> +}
>> +module_exit(aw_sar_i2c_exit);
>> +MODULE_DESCRIPTION("AWINIC SAR Driver");
>> +MODULE_LICENSE("GPL v2");
>> diff --git a/drivers/input/misc/aw_sar/aw_sar.h b/drivers/input/misc/aw_sar/aw_sar.h
>> new file mode 100644
>> index 000000000000..7a139f56e9c3
>> --- /dev/null
>> +++ b/drivers/input/misc/aw_sar/aw_sar.h
>> @@ -0,0 +1,15 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#ifndef AW_SAR_H_
>> +#define AW_SAR_H_
>> +
>> +void aw_sar_disable_irq(struct aw_sar *p_sar);
>> +void aw_sar_enable_irq(struct aw_sar *p_sar);
>> +
>> +int32_t aw_sar_soft_reset(struct aw_sar *p_sar);
>> +int32_t aw_sar_check_init_over_irq(struct aw_sar *p_sar);
>> +int32_t aw_sar_update_fw(struct aw_sar *p_sar);
>> +int32_t aw_sar_load_def_reg_bin(struct aw_sar *p_sar);
>> +void aw_sar_mode_set(struct aw_sar *p_sar, uint8_t curr_mode);
>> +int32_t aw_sar_update_reg_set_func(struct aw_sar *p_sar);
>
>
>Why is all this needed for one file and why is it here?
>
The patch for v3 will fix these issues.
>Best regards,
>Krzysztof
Kind regards,
Wang Shuaijie
