linux-kernel - Re: [PATCH v5 4/5] regulator: add regulator driver of hi655x pmic

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: <569CA1C5.3020005@hisilicon.com>
Date:	Mon, 18 Jan 2016 16:26:45 +0800
From:	chenfeng <puck.chen@...ilicon.com>
To:	Mark Brown <broonie@...nel.org>
CC:	<lee.jones@...aro.org>, <linux-kernel@...r.kernel.org>,
	<lgirdwood@...il.com>, <yudongbin@...ilicon.com>,
	<saberlily.xia@...ilicon.com>, <suzhuangluan@...ilicon.com>,
	<kong.kongxinwei@...ilicon.com>, <xuyiping@...ilicon.com>,
	<z.liuxinliang@...ilicon.com>, <puck.chenfeng@...il.com>,
	<weidong2@...ilicon.com>, <w.f@...wei.com>,
	<qijiwen@...ilicon.com>, <peter.panshilin@...ilicon.com>,
	<dan.zhao@...ilicon.com>, <linuxarm@...wei.com>,
	<liguozhu@...ilicon.com>
Subject: Re: [PATCH v5 4/5] regulator: add regulator driver of hi655x pmic



On 2016/1/16 2:07, Mark Brown wrote:
> On Tue, Jan 12, 2016 at 10:18:03AM +0800, chenfeng wrote:
>> On 2016/1/12 2:24, Mark Brown wrote:
>>> On Mon, Jan 11, 2016 at 08:20:16PM +0800, Chen Feng wrote:
> 
>>>> +config REGULATOR_HI655X
>>>> +	tristate "Hisilicon HI655X PMIC regulators support"
>>>> +	depends on ARCH_HISI || (COMPILE_TEST && ARM64)
> 
>>> Why does this depend on ARM64?  If it's needed it probably indicates a
>>> problem...
> 
>> There will be compile warning with arch parisc.
> 
>> Add the current support platform is ARM64.
> 
> The whole point of COMPILE_TEST is to allow people who are working
> generally rather than with the particular hardware to build things to
> improve build test coverage when doing general kernel work.  A warning
> on a very obscure architecture is really not a blocker here.
> 
ok, I will remove the ARM64 depends.
>> I am not sure about open coding regulators_node.
> 
>> I take max8907-regulator.c for reference. The code there is:
>> 224 static int max8907_regulator_parse_dt(struct platform_device *pdev)
> 
> The existance of older drivers that have not yet been converted to use
> newer core subsystem features is not a good reason to avoid using those
> core subsystem features.  You'll commonly find this situation in the
> kernel.
> 
>> Can you give me some references? Really thanks for your help.
> 
> $ grep -l regulators_node drivers/regulator/*.c
> drivers/regulator/88pm800.c
> drivers/regulator/axp20x-regulator.c
> drivers/regulator/da9062-regulator.c
> drivers/regulator/isl9305.c
> drivers/regulator/max14577.c
> drivers/regulator/max77686.c
> drivers/regulator/max77693.c
> drivers/regulator/max77802.c
> drivers/regulator/mt6311-regulator.c
> drivers/regulator/of_regulator.c
> drivers/regulator/pv88060-regulator.c
> drivers/regulator/pv88090-regulator.c
> drivers/regulator/rn5t618-regulator.c
> drivers/regulator/rt5033-regulator.c
> drivers/regulator/sky81452-regulator.c
> drivers/regulator/tps65023-regulator.c
> drivers/regulator/tps65086-regulator.c
> drivers/regulator/tps65217-regulator.c
> 
Understand, I will remove the match-table and add the regulators_node
to match the regulator-compatible in dts.