linux-kernel - Re: [PATCH v4] regulator: qcom-saw: Add support for SAW regulators

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: <56BB32A9.7090002@linaro.org>
Date:	Wed, 10 Feb 2016 14:52:57 +0200
From:	Georgi Djakov <georgi.djakov@...aro.org>
To:	Lina Iyer <lina.iyer@...aro.org>
Cc:	broonie@...nel.org, lgirdwood@...il.com, andy.gross@...aro.org,
	sboyd@...eaurora.org, linux-kernel@...r.kernel.org,
	linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v4] regulator: qcom-saw: Add support for SAW regulators

Hi Lina,
Thanks for reviewing.

On 02/10/2016 12:21 AM, Lina Iyer wrote:
> On Tue, Feb 09 2016 at 06:13 -0700, Georgi Djakov wrote:
[..]
>> +#define    SPM_REG_STS_1            0x10
>> +#define    SPM_REG_VCTL            0x14
>> +#define    SPM_REG_PMIC_DATA_0        0x28
>> +#define    SPM_REG_PMIC_DATA_1        0x2c
>> +#define    SPM_REG_RST            0x30
>> +
> These register offsets are SoC specific. You may want to follow the model
> of drivers/soc/qcom/spm.c in getting register offsets.
> 
> While I see that you are only supporting APQ8064 with this patch, you
> probably would want to think a bit far ahead. To support any other QCOM
> SoC, you would need extensive changes.
> 

The purpose of this patch it to add support for 8064. Supporting other 
SoCs requires just read/writing at different offsets. To handle this we
can convert the above defines to a table containing the offsets for each
SoC. I don't think these are extensive changes or do i miss something?

[..]
>> +
>> +module_platform_driver(qcom_saw_regulator_driver);
>> +
> builtin_platform_driver() perhaps ?
> 

It's tested as module too, so there is no reason to change to builtin.

Thanks,
Georgi