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: <53C8F050.6060104@samsung.com>
Date:	Fri, 18 Jul 2014 19:00:48 +0900
From:	Chanwoo Choi <cw00.choi@...sung.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-arm-kernel@...ts.infradead.org, jic23@...nel.org,
	ch.naveen@...sung.com, mark.rutland@....com,
	devicetree@...r.kernel.org, kgene.kim@...sung.com,
	pawel.moll@....com, ijc+devicetree@...lion.org.uk,
	linux-iio@...r.kernel.org, t.figa@...sung.com,
	rdunlap@...radead.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
	kyungmin.park@...sung.com, robh+dt@...nel.org, galak@...eaurora.org
Subject: Re: [PATCHv6 2/4] iio: adc: exynos_adc: Control special clock of ADC
 to support Exynos3250 ADC

Hi Arnd,

On 07/18/2014 06:47 PM, Arnd Bergmann wrote:
> On Friday 18 July 2014 14:59:44 Chanwoo Choi wrote:
>> This patch control special clock for ADC in Exynos series's FSYS block.
>> If special clock of ADC is registerd on clock list of common clk framework,
>> Exynos ADC drvier have to control this clock.
>>
>> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
>> - 'adc' clock: bus clock for ADC
>>
>> Exynos3250 has additional 'sclk_adc' clock as following:
>> - 'sclk_adc' clock: special clock for ADC which provide clock to internal ADC
>>
>> Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc' clock
>> in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_adc'
>> clock in FSYS_BLK.
> 
> Do you know if any of the older ADC blocks have an "sclk" input as well?

No, I didn't check older ADC blocks. I only checked it on Exynos3250,
Exynos4210/4212/4412, Exynos5250/5420.

> 
> Further, why is it called "sclk_adc" rather than just "sclk"?

The sclk means 'special clock' in Exynos TRM. Exynos SoC has varisou sclk clocks.
'sclk_adc' is only used for ADC IP.

> 
>> @@ -199,13 +262,20 @@ static void exynos_adc_v2_start_conv(struct exynos_adc *info,
>>         writel(con1 | ADC_CON_EN_START, ADC_V2_CON1(info->regs));
>>  }
>>  
>> +#define __EXYNOS_ADC_V2_DATA                           \
>> +       .num_channels   = MAX_ADC_V2_CHANNELS,          \
>> +       .init_hw        = exynos_adc_v2_init_hw,        \
>> +       .exit_hw        = exynos_adc_v2_exit_hw,        \
>> +       .clear_irq      = exynos_adc_v2_clear_irq,      \
>> +       .start_conv     = exynos_adc_v2_start_conv,     \
>> +
>>  static struct exynos_adc_data const exynos_adc_v2_data = {
>> -       .num_channels   = MAX_ADC_V2_CHANNELS,
>> +       __EXYNOS_ADC_V2_DATA
>> +};
>>  
>> -       .init_hw        = exynos_adc_v2_init_hw,
>> -       .exit_hw        = exynos_adc_v2_exit_hw,
>> -       .clear_irq      = exynos_adc_v2_clear_irq,
>> -       .start_conv     = exynos_adc_v2_start_conv,
>> +static struct exynos_adc_data const exynos3250_adc_v2_data = {
>> +       __EXYNOS_ADC_V2_DATA
>> +       .needs_sclk = true,
>>  };
> 
> I think the macro hurts readability. Please just duplicate the definition
> here.

OK, I'll fix it.

> 
>>  static const struct of_device_id exynos_adc_match[] = {
>> @@ -215,6 +285,9 @@ static const struct of_device_id exynos_adc_match[] = {
>>         }, {
>>                 .compatible = "samsung,exynos-adc-v2",
>>                 .data = (void *)&exynos_adc_v2_data,
>> +       }, {
>> +               .compatible = "samsung,exynos3250-adc-v2",
>> +               .data = (void *)&exynos3250_adc_v2_data,
>>         },
>>         {},
> 
> Remove the '(void *)' cast here and mark the structure as 'const'.
> We intentionally use a 'const void *' type here to verify that
> the driver doesn't modify the per-device type data at runtime,
> which would be bad if you ever have multiple device instances.

OK, I'll remove it.

Thanks,
Chanwoo Choi


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ