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]
Date:	Thu, 07 Feb 2013 10:43:23 +0900
From:	jonghwa3.lee@...sung.com
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, a.zummo@...ertech.it,
	rtc-linux@...glegroups.com
Subject: Re: [PATCH] rtc: max8997: Add driver for max8997 rtc.

On 2013년 02월 07일 06:06, Andrew Morton wrote:
> On Wed, 06 Feb 2013 20:23:05 +0900
> Jonghwa Lee <jonghwa3.lee@...sung.com> wrote:
> 
>> This patch adds rtc driver for Maxim 8997 multifunction chip.
>> Max8997 has rtc module in it. and it can be used for timekeeping
>> clock and system alarm. It provide various operational mode those are
>> BCD/binary, 24/12hour, am/pm. Driver sets binary/24/ for default.
>> Maxim 8997 also supports SMPL(Sudden Momentary Power Loss), WTSR
>> (Watchdog Timeout and Software Reset).
>>
>> ...
>>
>> --- a/drivers/rtc/Kconfig
>> +++ b/drivers/rtc/Kconfig
>> @@ -233,6 +233,36 @@ config RTC_DRV_MAX8998
>>  	  This driver can also be built as a module. If so, the module
>>  	  will be called rtc-max8998.
>>  
>> +config RTC_DRV_MAX8997
>> +	tristate "Maxim MAX8997"
>> +	depends on MFD_MAX8997
>> +	help
>> +	  If you say yes here you will get support for the
>> +	  RTC of Maxim MAX8997 PMIC.
>> +
>> +	  This driver can also be built as a module. If so, the module
>> +	  will be called rtc-max8997.
>> +
>> +config MAX8997_RTC_WTSR
>> +	bool "MAX8997_RTC_WTSR"
>> +	depends on RTC_DRV_MAX8997
>> +	help
>> +	  MAX8997 rtc can supports WTSR(Watchdog Timeout and Software Reset).
>> +	  WTSR event would keep the PMIC on regardless of PWRHOLD signal.
>> +	  When PWRHOLD signal is falling, it turns on WTSR timer rather executes
>> +	  reset imidiately. After timer expiring, it determine to reset the PMIC
>> +	  depends on PWRHOLD state.
>> +
>> +config MAX8997_RTC_SMPL
>> +	bool "MAX8997_RTC_SMPL"
>> +	depends on RTC_DRV_MAX8997
>> +	help
>> +	  MAX8997 rtc can supports SMPL(Sudden Momentary Power Loss).
>> +	  SMPL function can be used to intiate a power up sequence after momentarily
>> +	  loosing contact to the battery pack. If battery goes under UVLO(Under
>> +	  Lock Out) it starts SMPL timer. After timer exipiring, it checks battery
>> +	  whether its state recovers from UVLO or not to make power supplies keep on.
> 
> Can we avoid creating CONFIG_MAX8997_RTC_WTSR and
> CONFIG_MAX8997_RTC_SMPL?  It would be much better for the users if
> these features were always available in all kernel builds.
> 
Okay, I'll apply it.

> The best way of handling this sort of thing is for the driver to probe
> the hardware, work out its capabilities and "do the right thing".
> 
> The second best way is to require that the user add certain module
> parameters to enable the functionality.
> 

How do we create sysfs node for enabling these options?


Thanks,
Jonghwa

> The worst way is to require the user to make the decision at kernel
> build time!
> 
> 
--
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