Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1310346 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v5 4/5] regulator: add regulator driver of hi655x pmic Mark Brown <broonie@kernel.org> - 2016-01-15 19:10 +0100
    Re: [PATCH v5 4/5] regulator: add regulator driver of hi655x pmic chenfeng <puck.chen@hisilicon.com> - 2016-01-18 09:30 +0100

#1310346 — Re: [PATCH v5 4/5] regulator: add regulator driver of hi655x pmic

[Multipart message — attachments visible in raw view] — view raw

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.

> 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

[toc] | [next] | [standalone]

#1311374

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web