From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754303AbcARI06 (ORCPT ); Mon, 18 Jan 2016 03:26:58 -0500 Received: from szxga03-in.huawei.com ([119.145.14.66]:13226 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754282AbcARI0z (ORCPT ); Mon, 18 Jan 2016 03:26:55 -0500 Subject: Re: [PATCH v5 4/5] regulator: add regulator driver of hi655x pmic To: Mark Brown References: <1452514817-118311-1-git-send-email-puck.chen@hisilicon.com> <1452514817-118311-5-git-send-email-puck.chen@hisilicon.com> <20160111182444.GR6588@sirena.org.uk> <5694625B.9060304@hisilicon.com> <20160115180740.GD6588@sirena.org.uk> CC: , , , , , , , , , , , , , , , , From: chenfeng Message-ID: <569CA1C5.3020005@hisilicon.com> Date: Mon, 18 Jan 2016 16:26:45 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20160115180740.GD6588@sirena.org.uk> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.142.192.172] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.569CA1CC.0060,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 49dc8dc0810a937b15ef97c8030297dd Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.