Re: [PATCH] rtc: max8997: Add driver for max8997 rtc.

[Andrew Morton]

On Wed, 06 Feb 2013 20:23:05 +0900
Jonghwa Lee <jonghwa3.lee@xxxxxxxxxxx> 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.

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.

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/