linux-kernel - Re: [PATCH next v4 1/2] i2c: hisi: Add initial device tree support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <64721a3f-8fa4-45b4-1045-544cdd021bd8@huawei.com>
Date:   Tue, 13 Sep 2022 17:01:57 +0800
From:   chenweilong <chenweilong@...wei.com>
To:     Yicong Yang <yangyicong@...wei.com>, <yangyicong@...ilicon.com>,
        <xuwei5@...wei.com>, <wsa@...nel.org>, <robh+dt@...nel.org>
CC:     <linux-i2c@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>
Subject: Re: [PATCH next v4 1/2] i2c: hisi: Add initial device tree support

On 2022/9/13 15:48, Yicong Yang wrote:
> On 2022/9/9 15:48, Weilong Chen wrote:
>> The HiSilicon I2C controller can be used on embedded platform, which
>> boot from devicetree.
>>
>> Signed-off-by: Weilong Chen <chenweilong@...wei.com>
>> ---
>>  drivers/i2c/busses/Kconfig    |  2 +-
>>  drivers/i2c/busses/i2c-hisi.c | 19 ++++++++++++++++++-
>>  2 files changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
>> index 7284206b278b..6d0fdf48e97d 100644
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -673,7 +673,7 @@ config I2C_HIGHLANDER
>>  
>>  config I2C_HISI
>>  	tristate "HiSilicon I2C controller"
>> -	depends on (ARM64 && ACPI) || COMPILE_TEST
>> +	depends on ARM64 || COMPILE_TEST
>>  	help
>>  	  Say Y here if you want to have Hisilicon I2C controller support
>>  	  available on the Kunpeng Server.
>> diff --git a/drivers/i2c/busses/i2c-hisi.c b/drivers/i2c/busses/i2c-hisi.c
>> index 76c3d8f6fc3c..7a77f306d05f 100644
>> --- a/drivers/i2c/busses/i2c-hisi.c
>> +++ b/drivers/i2c/busses/i2c-hisi.c
>> @@ -5,6 +5,9 @@
>>   * Copyright (c) 2021 HiSilicon Technologies Co., Ltd.
>>   */
>>  
>> +#ifdef CONFIG_ACPI
>> +#include <linux/acpi.h>
>> +#endif
>>  #include <linux/bits.h>
>>  #include <linux/bitfield.h>
>>  #include <linux/completion.h>
>> @@ -13,6 +16,9 @@
>>  #include <linux/io.h>
>>  #include <linux/module.h>
>>  #include <linux/mod_devicetable.h>
>> +#ifdef CONFIG_OF
>> +#include <linux/of.h>
>> +#endif
> I don't think the protection for the headers is necessary and common. The
> ACPI/OF specific functions should have already been handled well with{out}
> ACPI/OF config. Have you met some problems without these?
>
> BTW, it's better to have a changelog when updating the patches.

This kind usage does exist in the kernel, for example: drivers/rtc/rtc-mc146818-lib.c.

It can be consistent with the protection below MODULE_DEVICE_TABLE.

>>  #include <linux/platform_device.h>
>>  #include <linux/property.h>
>>  #include <linux/units.h>
>> @@ -483,17 +489,28 @@ static int hisi_i2c_probe(struct platform_device *pdev)
>>  	return 0;
>>  }
>>  
>> +#ifdef CONFIG_ACPI
>>  static const struct acpi_device_id hisi_i2c_acpi_ids[] = {
>>  	{ "HISI03D1", 0 },
>>  	{ }
>>  };
>>  MODULE_DEVICE_TABLE(acpi, hisi_i2c_acpi_ids);
>> +#endif
>> +
>> +#ifdef CONFIG_OF
>> +static const struct of_device_id hisi_i2c_dts_ids[] = {
>> +	{ .compatible = "hisilicon,hisi-i2c", },
>> +	{ }
>> +};
>> +MODULE_DEVICE_TABLE(of, hisi_i2c_dts_ids);
>> +#endif
>>  
>>  static struct platform_driver hisi_i2c_driver = {
>>  	.probe		= hisi_i2c_probe,
>>  	.driver		= {
>>  		.name	= "hisi-i2c",
>> -		.acpi_match_table = hisi_i2c_acpi_ids,
>> +		.acpi_match_table = ACPI_PTR(hisi_i2c_acpi_ids),
>> +		.of_match_table = of_match_ptr(hisi_i2c_dts_ids),
>>  	},
>>  };
>>  module_platform_driver(hisi_i2c_driver);
>>
> .