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: <56A84636.2000107@samsung.com>
Date:	Wed, 27 Jan 2016 13:23:18 +0900
From:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
To:	Javier Martinez Canillas <javier@....samsung.com>,
	linux-kernel@...r.kernel.org
Cc:	Kukjin Kim <kgene@...nel.org>, rtc-linux@...glegroups.com,
	Andi Shyti <andi.shyti@...sung.com>,
	Chanwoo Choi <cw00.choi@...sung.com>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Laxman Dewangan <ldewangan@...dia.com>,
	linux-samsung-soc@...r.kernel.org
Subject: Re: [PATCH v4 06/10] rtc: max77686: Add max77802 support

On 27.01.2016 12:36, Javier Martinez Canillas wrote:
> The MAX77686 and MAX77802 RTC IP blocks are very similar with only
> these differences:
> 
> 0) The RTC registers layout and addresses are different.
> 
> 1) The MAX77686 use 1 bit of the sec/min/hour/etc registers as the
>    alarm enable while MAX77802 has a separate register for that.
> 
> 2) The MAX77686 RTCYEAR register valid values range is 0..99 while
>    for MAX77802 is 0..199.
> 
> 3) The MAX77686 has a separate I2C address for the RTC registers
>    while the MAX77802 uses the same I2C address as the PMIC regs.
> 
> 5) The minimum delay before a RTC update (16 msecs vs 200 usecs).
> 
> There are separate drivers for MAX77686 and MAX77802 RTC IP blocks
> but the differences are not that big so the driver can be extended
> to support both instead of duplicating a lot of code in 2 drivers.
> 
> Suggested-by: Krzysztof Kozlowski <k.kozlowski@...sung.com>
> Signed-off-by: Javier Martinez Canillas <javier@....samsung.com>
> Acked-by: Laxman Dewangan <ldewangan@...dia.com>
> Tested-by: Krzysztof Kozlowski <k.kozlowski@...sung.com>
> Reviewed-by: Andi Shyti <andi.shyti@...sung.com>
> 
> ---
> 
> Changes in v4:
> - Add Krzysztof Kozlowski's Tested-by tag to patch #6.
> - Add Andi Shyti's Reviewed-by tag to patch #6.
> - Reverse alarm enable reg check logic. Suggeted by Krzysztof Kozlowski.
> - Return early to avoid an else statement. Suggested by Andi Shyti.
> 
> Changes in v3:
> - Add Laxman Dewangan's Acked-by tag to patch #6.
> 
> Changes in v2:
> - Add a MAX77802 prefix to ALARM_ENABLE_VALUE. Suggested by Krzysztof Kozlowski.
> - Rename .rtcae to .alarm_enable_reg and .rtcrm to .separate_i2c_addr.
>   Suggested by Krzysztof Kozlowski.
> - Don't use func and LINE in error messages. Suggested by Krzysztof Kozlowski.
> - Remove REG_RTC_AE2 since is not used by neither max77686 nor max77802.
> - Check if REG_RTC_AE1 has a valid address before accessing it.
> 
>  drivers/rtc/rtc-max77686.c | 196 ++++++++++++++++++++++++++++++++++++---------
>  1 file changed, 156 insertions(+), 40 deletions(-)
> 

Reviewed-by: Krzysztof Kozlowski <k.kozlowski@...sung.com>

One comment at the end...

[...]


> @@ -524,6 +636,9 @@ static int max77686_rtc_probe(struct platform_device *pdev)
>  	info->drv_data = (const struct max77686_rtc_driver_data *)
>  		id->driver_data;
>  
> +	if (!info->drv_data->separate_i2c_addr)
> +		info->max77686->rtc_regmap = info->max77686->regmap;
> +

At this stage I don't like the idea of messing with parent's state
structure. The driver should not modify any of parents data (the best
way would be to take a pointer to const). In this patch this looks like
breaking the encapsulation. If the parent is responsible for regmaps,
then the parent should set rtc_regmap for children (parent also knows
what type device it is working on).

...but I am assuming that a new patch will be following this one - the
patch moving ownership of i2c dummy and regmap to the RTC driver. In
that case this code makes a lot more sense. Am I thinking correctly?

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ