char: legacy RTC cleanups

char: legacy RTC cleanups

[Arnd Bergmann]

I've had these patches in my tree for a while, after the first one
had a few issues that are fixed in this new version. The old-style
PC RTC driver is now also disabled on m68k (as pointed out by
Geert), ppc (it was also blacklisted), and m32r (I showed that
it did not build).

For the genrtc driver, rearranging the headers makes it simpler
to use and reduces duplication. In case of alpha and mn10300,
I've shown that the genrtc and rtc drivers are doing the same
thing, so we don't need them both. The remaining three
architectures (m68k, parisc, powerpc) actually all support
the newer rtc-generic driver, so we could remove genrtc completely
if we want to.

	Arnd

[rtc-linux] char: legacy RTC cleanups

[Arnd Bergmann]

I've had these patches in my tree for a while, after the first one
had a few issues that are fixed in this new version. The old-style
PC RTC driver is now also disabled on m68k (as pointed out by
Geert), ppc (it was also blacklisted), and m32r (I showed that
it did not build).

For the genrtc driver, rearranging the headers makes it simpler
to use and reduces duplication. In case of alpha and mn10300,
I've shown that the genrtc and rtc drivers are doing the same
thing, so we don't need them both. The remaining three
architectures (m68k, parisc, powerpc) actually all support
the newer rtc-generic driver, so we could remove genrtc completely
if we want to.

	Arnd

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

char: legacy RTC cleanups

[Arnd Bergmann]

I've had these patches in my tree for a while, after the first one
had a few issues that are fixed in this new version. The old-style
PC RTC driver is now also disabled on m68k (as pointed out by
Geert), ppc (it was also blacklisted), and m32r (I showed that
it did not build).

For the genrtc driver, rearranging the headers makes it simpler
to use and reduces duplication. In case of alpha and mn10300,
I've shown that the genrtc and rtc drivers are doing the same
thing, so we don't need them both. The remaining three
architectures (m68k, parisc, powerpc) actually all support
the newer rtc-generic driver, so we could remove genrtc completely
if we want to.

	Arnd

[PATCH 1/8] char/rtc: replace blacklist with whitelist

[Arnd Bergmann]

Every new architecture has to add itself to the growing list of those
that do not support the legacy PC RTC driver.

This replaces the long list of architectures that don't support it
with a shorter list of those that do.

The list is taken from those architectures that have a non-empty
asm/mc146818rtc.h header file and were not explicitly blacklisted.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/char/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 3ec0766ed5e9..66b5d48f409a 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -279,8 +279,7 @@ if RTC_LIB=n
 
 config RTC
 	tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
-	depends on !PPC && !PARISC && !IA64 && !M68K && !SPARC && !FRV \
-			&& !ARM && !SUPERH && !S390 && !AVR32 && !BLACKFIN && !UML
+	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300 || X86
 	---help---
 	  If you say Y here and create a character special file /dev/rtc with
 	  major number 10 and minor number 135 using mknod ("man mknod"), you
-- 
2.7.0

[rtc-linux] [PATCH 1/8] char/rtc: replace blacklist with whitelist

[Arnd Bergmann]

Every new architecture has to add itself to the growing list of those
that do not support the legacy PC RTC driver.

This replaces the long list of architectures that don't support it
with a shorter list of those that do.

The list is taken from those architectures that have a non-empty
asm/mc146818rtc.h header file and were not explicitly blacklisted.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/char/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 3ec0766ed5e9..66b5d48f409a 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -279,8 +279,7 @@ if RTC_LIB=n
 
 config RTC
 	tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
-	depends on !PPC && !PARISC && !IA64 && !M68K && !SPARC && !FRV \
-			&& !ARM && !SUPERH && !S390 && !AVR32 && !BLACKFIN && !UML
+	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300 || X86
 	---help---
 	  If you say Y here and create a character special file /dev/rtc with
 	  major number 10 and minor number 135 using mknod ("man mknod"), you
-- 
2.7.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PATCH 1/8] char/rtc: replace blacklist with whitelist

[Arnd Bergmann]

Every new architecture has to add itself to the growing list of those
that do not support the legacy PC RTC driver.

This replaces the long list of architectures that don't support it
with a shorter list of those that do.

The list is taken from those architectures that have a non-empty
asm/mc146818rtc.h header file and were not explicitly blacklisted.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/char/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 3ec0766ed5e9..66b5d48f409a 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -279,8 +279,7 @@ if RTC_LIB=n
 
 config RTC
 	tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
-	depends on !PPC && !PARISC && !IA64 && !M68K && !SPARC && !FRV \
-			&& !ARM && !SUPERH && !S390 && !AVR32 && !BLACKFIN && !UML
+	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300 || X86
 	---help---
 	  If you say Y here and create a character special file /dev/rtc with
 	  major number 10 and minor number 135 using mknod ("man mknod"), you
-- 
2.7.0

Re: [PATCH 1/8] char/rtc: replace blacklist with whitelist

[Alexandre Belloni]

On 26/04/2016 at 23:44:05 +0200, Arnd Bergmann wrote :
> Every new architecture has to add itself to the growing list of those
> that do not support the legacy PC RTC driver.
> 
> This replaces the long list of architectures that don't support it
> with a shorter list of those that do.
> 
> The list is taken from those architectures that have a non-empty
> asm/mc146818rtc.h header file and were not explicitly blacklisted.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

> ---
>  drivers/char/Kconfig | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> index 3ec0766ed5e9..66b5d48f409a 100644
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -279,8 +279,7 @@ if RTC_LIB=n
>  
>  config RTC
>  	tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
> -	depends on !PPC && !PARISC && !IA64 && !M68K && !SPARC && !FRV \
> -			&& !ARM && !SUPERH && !S390 && !AVR32 && !BLACKFIN && !UML
> +	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300 || X86
>  	---help---
>  	  If you say Y here and create a character special file /dev/rtc with
>  	  major number 10 and minor number 135 using mknod ("man mknod"), you
> -- 
> 2.7.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[rtc-linux] Re: [PATCH 1/8] char/rtc: replace blacklist with whitelist

[Alexandre Belloni]

On 26/04/2016 at 23:44:05 +0200, Arnd Bergmann wrote :
> Every new architecture has to add itself to the growing list of those
> that do not support the legacy PC RTC driver.
> 
> This replaces the long list of architectures that don't support it
> with a shorter list of those that do.
> 
> The list is taken from those architectures that have a non-empty
> asm/mc146818rtc.h header file and were not explicitly blacklisted.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

> ---
>  drivers/char/Kconfig | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> index 3ec0766ed5e9..66b5d48f409a 100644
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -279,8 +279,7 @@ if RTC_LIB=n
>  
>  config RTC
>  	tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
> -	depends on !PPC && !PARISC && !IA64 && !M68K && !SPARC && !FRV \
> -			&& !ARM && !SUPERH && !S390 && !AVR32 && !BLACKFIN && !UML
> +	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300 || X86
>  	---help---
>  	  If you say Y here and create a character special file /dev/rtc with
>  	  major number 10 and minor number 135 using mknod ("man mknod"), you
> -- 
> 2.7.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 1/8] char/rtc: replace blacklist with whitelist

[Alexandre Belloni]

On 26/04/2016 at 23:44:05 +0200, Arnd Bergmann wrote :
> Every new architecture has to add itself to the growing list of those
> that do not support the legacy PC RTC driver.
> 
> This replaces the long list of architectures that don't support it
> with a shorter list of those that do.
> 
> The list is taken from those architectures that have a non-empty
> asm/mc146818rtc.h header file and were not explicitly blacklisted.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

> ---
>  drivers/char/Kconfig | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> index 3ec0766ed5e9..66b5d48f409a 100644
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -279,8 +279,7 @@ if RTC_LIB=n
>  
>  config RTC
>  	tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
> -	depends on !PPC && !PARISC && !IA64 && !M68K && !SPARC && !FRV \
> -			&& !ARM && !SUPERH && !S390 && !AVR32 && !BLACKFIN && !UML
> +	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300 || X86
>  	---help---
>  	  If you say Y here and create a character special file /dev/rtc with
>  	  major number 10 and minor number 135 using mknod ("man mknod"), you
> -- 
> 2.7.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 2/8] char/rtc: legacy RTC is no longer supported on x86

[Arnd Bergmann]

Commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") had
the side-effect of unconditionally enabling the RTC_LIB symbol on x86,
which in turn disables the selection of the CONFIG_RTC and
CONFIG_GEN_RTC drivers that contain a two older implementations of
the CONFIG_RTC_DRV_CMOS driver.

This removes x86 from the list.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/char/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 66b5d48f409a..9bdb629fbaae 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -279,7 +279,7 @@ if RTC_LIB=n
 
 config RTC
 	tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
-	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300 || X86
+	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300
 	---help---
 	  If you say Y here and create a character special file /dev/rtc with
 	  major number 10 and minor number 135 using mknod ("man mknod"), you
@@ -328,7 +328,7 @@ config JS_RTC
 config GEN_RTC
 	tristate "Generic /dev/rtc emulation"
 	depends on RTC!=y
-	depends on ALPHA || M68K || MN10300 || PARISC || PPC || X86
+	depends on ALPHA || M68K || MN10300 || PARISC || PPC
 	---help---
 	  If you say Y here and create a character special file /dev/rtc with
 	  major number 10 and minor number 135 using mknod ("man mknod"), you
-- 
2.7.0

[rtc-linux] [PATCH 2/8] char/rtc: legacy RTC is no longer supported on x86

[Arnd Bergmann]

Commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") had
the side-effect of unconditionally enabling the RTC_LIB symbol on x86,
which in turn disables the selection of the CONFIG_RTC and
CONFIG_GEN_RTC drivers that contain a two older implementations of
the CONFIG_RTC_DRV_CMOS driver.

This removes x86 from the list.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/char/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 66b5d48f409a..9bdb629fbaae 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -279,7 +279,7 @@ if RTC_LIB=n
 
 config RTC
 	tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
-	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300 || X86
+	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300
 	---help---
 	  If you say Y here and create a character special file /dev/rtc with
 	  major number 10 and minor number 135 using mknod ("man mknod"), you
@@ -328,7 +328,7 @@ config JS_RTC
 config GEN_RTC
 	tristate "Generic /dev/rtc emulation"
 	depends on RTC!=y
-	depends on ALPHA || M68K || MN10300 || PARISC || PPC || X86
+	depends on ALPHA || M68K || MN10300 || PARISC || PPC
 	---help---
 	  If you say Y here and create a character special file /dev/rtc with
 	  major number 10 and minor number 135 using mknod ("man mknod"), you
-- 
2.7.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PATCH 2/8] char/rtc: legacy RTC is no longer supported on x86

[Arnd Bergmann]

Commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") had
the side-effect of unconditionally enabling the RTC_LIB symbol on x86,
which in turn disables the selection of the CONFIG_RTC and
CONFIG_GEN_RTC drivers that contain a two older implementations of
the CONFIG_RTC_DRV_CMOS driver.

This removes x86 from the list.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/char/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 66b5d48f409a..9bdb629fbaae 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -279,7 +279,7 @@ if RTC_LIB=n
 
 config RTC
 	tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
-	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300 || X86
+	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300
 	---help---
 	  If you say Y here and create a character special file /dev/rtc with
 	  major number 10 and minor number 135 using mknod ("man mknod"), you
@@ -328,7 +328,7 @@ config JS_RTC
 config GEN_RTC
 	tristate "Generic /dev/rtc emulation"
 	depends on RTC!=y
-	depends on ALPHA || M68K || MN10300 || PARISC || PPC || X86
+	depends on ALPHA || M68K || MN10300 || PARISC || PPC
 	---help---
 	  If you say Y here and create a character special file /dev/rtc with
 	  major number 10 and minor number 135 using mknod ("man mknod"), you
-- 
2.7.0

Re: [PATCH 2/8] char/rtc: legacy RTC is no longer supported on x86

[Alexandre Belloni]

On 26/04/2016 at 23:44:06 +0200, Arnd Bergmann wrote :
> Commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") had
> the side-effect of unconditionally enabling the RTC_LIB symbol on x86,
> which in turn disables the selection of the CONFIG_RTC and
> CONFIG_GEN_RTC drivers that contain a two older implementations of
> the CONFIG_RTC_DRV_CMOS driver.
> 
> This removes x86 from the list.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

Two down, still four drivers for the x86 RTCs...


> ---
>  drivers/char/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> index 66b5d48f409a..9bdb629fbaae 100644
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -279,7 +279,7 @@ if RTC_LIB=n
>  
>  config RTC
>  	tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
> -	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300 || X86
> +	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300
>  	---help---
>  	  If you say Y here and create a character special file /dev/rtc with
>  	  major number 10 and minor number 135 using mknod ("man mknod"), you
> @@ -328,7 +328,7 @@ config JS_RTC
>  config GEN_RTC
>  	tristate "Generic /dev/rtc emulation"
>  	depends on RTC!=y
> -	depends on ALPHA || M68K || MN10300 || PARISC || PPC || X86
> +	depends on ALPHA || M68K || MN10300 || PARISC || PPC
>  	---help---
>  	  If you say Y here and create a character special file /dev/rtc with
>  	  major number 10 and minor number 135 using mknod ("man mknod"), you
> -- 
> 2.7.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[rtc-linux] Re: [PATCH 2/8] char/rtc: legacy RTC is no longer supported on x86

[Alexandre Belloni]

On 26/04/2016 at 23:44:06 +0200, Arnd Bergmann wrote :
> Commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") had
> the side-effect of unconditionally enabling the RTC_LIB symbol on x86,
> which in turn disables the selection of the CONFIG_RTC and
> CONFIG_GEN_RTC drivers that contain a two older implementations of
> the CONFIG_RTC_DRV_CMOS driver.
> 
> This removes x86 from the list.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

Two down, still four drivers for the x86 RTCs...


> ---
>  drivers/char/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> index 66b5d48f409a..9bdb629fbaae 100644
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -279,7 +279,7 @@ if RTC_LIB=n
>  
>  config RTC
>  	tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
> -	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300 || X86
> +	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300
>  	---help---
>  	  If you say Y here and create a character special file /dev/rtc with
>  	  major number 10 and minor number 135 using mknod ("man mknod"), you
> @@ -328,7 +328,7 @@ config JS_RTC
>  config GEN_RTC
>  	tristate "Generic /dev/rtc emulation"
>  	depends on RTC!=y
> -	depends on ALPHA || M68K || MN10300 || PARISC || PPC || X86
> +	depends on ALPHA || M68K || MN10300 || PARISC || PPC
>  	---help---
>  	  If you say Y here and create a character special file /dev/rtc with
>  	  major number 10 and minor number 135 using mknod ("man mknod"), you
> -- 
> 2.7.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 2/8] char/rtc: legacy RTC is no longer supported on x86

[Alexandre Belloni]

On 26/04/2016 at 23:44:06 +0200, Arnd Bergmann wrote :
> Commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") had
> the side-effect of unconditionally enabling the RTC_LIB symbol on x86,
> which in turn disables the selection of the CONFIG_RTC and
> CONFIG_GEN_RTC drivers that contain a two older implementations of
> the CONFIG_RTC_DRV_CMOS driver.
> 
> This removes x86 from the list.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

Two down, still four drivers for the x86 RTCs...


> ---
>  drivers/char/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> index 66b5d48f409a..9bdb629fbaae 100644
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -279,7 +279,7 @@ if RTC_LIB=n
>  
>  config RTC
>  	tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
> -	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300 || X86
> +	depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300
>  	---help---
>  	  If you say Y here and create a character special file /dev/rtc with
>  	  major number 10 and minor number 135 using mknod ("man mknod"), you
> @@ -328,7 +328,7 @@ config JS_RTC
>  config GEN_RTC
>  	tristate "Generic /dev/rtc emulation"
>  	depends on RTC!=y
> -	depends on ALPHA || M68K || MN10300 || PARISC || PPC || X86
> +	depends on ALPHA || M68K || MN10300 || PARISC || PPC
>  	---help---
>  	  If you say Y here and create a character special file /dev/rtc with
>  	  major number 10 and minor number 135 using mknod ("man mknod"), you
> -- 
> 2.7.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH 2/8] char/rtc: legacy RTC is no longer supported on x86

[Thomas Gleixner]

On Tue, 26 Apr 2016, Arnd Bergmann wrote:

> Commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") had
> the side-effect of unconditionally enabling the RTC_LIB symbol on x86,
> which in turn disables the selection of the CONFIG_RTC and
> CONFIG_GEN_RTC drivers that contain a two older implementations of
> the CONFIG_RTC_DRV_CMOS driver.
> 
> This removes x86 from the list.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>

Re: [PATCH 2/8] char/rtc: legacy RTC is no longer supported on x86

[Thomas Gleixner]

On Tue, 26 Apr 2016, Arnd Bergmann wrote:

> Commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") had
> the side-effect of unconditionally enabling the RTC_LIB symbol on x86,
> which in turn disables the selection of the CONFIG_RTC and
> CONFIG_GEN_RTC drivers that contain a two older implementations of
> the CONFIG_RTC_DRV_CMOS driver.
> 
> This removes x86 from the list.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>

[PATCH 3/8] char/rtc: remove empty asm/mc146818rtc.h files

[Arnd Bergmann]

Nothing on these architectures ever includes the asm/mc146818rtc.h
file, the drivers that used to do this have been fixed long ago,
and the remaining users are all PC-specific.

This removes the files for good.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/frv/include/asm/mc146818rtc.h    | 16 ----------------
 arch/h8300/include/asm/mc146818rtc.h  |  9 ---------
 arch/ia64/include/asm/mc146818rtc.h   | 10 ----------
 arch/parisc/include/asm/mc146818rtc.h |  9 ---------
 arch/sh/include/asm/mc146818rtc.h     |  7 -------
 5 files changed, 51 deletions(-)
 delete mode 100644 arch/frv/include/asm/mc146818rtc.h
 delete mode 100644 arch/h8300/include/asm/mc146818rtc.h
 delete mode 100644 arch/ia64/include/asm/mc146818rtc.h
 delete mode 100644 arch/parisc/include/asm/mc146818rtc.h
 delete mode 100644 arch/sh/include/asm/mc146818rtc.h

diff --git a/arch/frv/include/asm/mc146818rtc.h b/arch/frv/include/asm/mc146818rtc.h
deleted file mode 100644
index 90dfb7a633d1..000000000000
--- a/arch/frv/include/asm/mc146818rtc.h
+++ /dev/null
@@ -1,16 +0,0 @@
-/* mc146818rtc.h: RTC defs
- *
- * Copyright (C) 2005 Red Hat, Inc. All Rights Reserved.
- * Written by David Howells (dhowells@redhat.com)
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#ifndef _ASM_MC146818RTC_H
-#define _ASM_MC146818RTC_H
-
-
-#endif /* _ASM_MC146818RTC_H */
diff --git a/arch/h8300/include/asm/mc146818rtc.h b/arch/h8300/include/asm/mc146818rtc.h
deleted file mode 100644
index ab9d9646d241..000000000000
--- a/arch/h8300/include/asm/mc146818rtc.h
+++ /dev/null
@@ -1,9 +0,0 @@
-/*
- * Machine dependent access functions for RTC registers.
- */
-#ifndef _H8300_MC146818RTC_H
-#define _H8300_MC146818RTC_H
-
-/* empty include file to satisfy the include in genrtc.c/ide-geometry.c */
-
-#endif /* _H8300_MC146818RTC_H */
diff --git a/arch/ia64/include/asm/mc146818rtc.h b/arch/ia64/include/asm/mc146818rtc.h
deleted file mode 100644
index 407787a237ba..000000000000
--- a/arch/ia64/include/asm/mc146818rtc.h
+++ /dev/null
@@ -1,10 +0,0 @@
-#ifndef _ASM_IA64_MC146818RTC_H
-#define _ASM_IA64_MC146818RTC_H
-
-/*
- * Machine dependent access functions for RTC registers.
- */
-
-/* empty include file to satisfy the include in genrtc.c */
-
-#endif /* _ASM_IA64_MC146818RTC_H */
diff --git a/arch/parisc/include/asm/mc146818rtc.h b/arch/parisc/include/asm/mc146818rtc.h
deleted file mode 100644
index adf41631449f..000000000000
--- a/arch/parisc/include/asm/mc146818rtc.h
+++ /dev/null
@@ -1,9 +0,0 @@
-/*
- * Machine dependent access functions for RTC registers.
- */
-#ifndef _ASM_MC146818RTC_H
-#define _ASM_MC146818RTC_H
-
-/* empty include file to satisfy the include in genrtc.c */
-
-#endif /* _ASM_MC146818RTC_H */
diff --git a/arch/sh/include/asm/mc146818rtc.h b/arch/sh/include/asm/mc146818rtc.h
deleted file mode 100644
index 0aee96a97330..000000000000
--- a/arch/sh/include/asm/mc146818rtc.h
+++ /dev/null
@@ -1,7 +0,0 @@
-/*
- * Machine dependent access functions for RTC registers.
- */
-#ifndef _ASM_MC146818RTC_H
-#define _ASM_MC146818RTC_H
-
-#endif /* _ASM_MC146818RTC_H */
-- 
2.7.0

[rtc-linux] [PATCH 3/8] char/rtc: remove empty asm/mc146818rtc.h files

[Arnd Bergmann]

Nothing on these architectures ever includes the asm/mc146818rtc.h
file, the drivers that used to do this have been fixed long ago,
and the remaining users are all PC-specific.

This removes the files for good.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/frv/include/asm/mc146818rtc.h    | 16 ----------------
 arch/h8300/include/asm/mc146818rtc.h  |  9 ---------
 arch/ia64/include/asm/mc146818rtc.h   | 10 ----------
 arch/parisc/include/asm/mc146818rtc.h |  9 ---------
 arch/sh/include/asm/mc146818rtc.h     |  7 -------
 5 files changed, 51 deletions(-)
 delete mode 100644 arch/frv/include/asm/mc146818rtc.h
 delete mode 100644 arch/h8300/include/asm/mc146818rtc.h
 delete mode 100644 arch/ia64/include/asm/mc146818rtc.h
 delete mode 100644 arch/parisc/include/asm/mc146818rtc.h
 delete mode 100644 arch/sh/include/asm/mc146818rtc.h

diff --git a/arch/frv/include/asm/mc146818rtc.h b/arch/frv/include/asm/mc146818rtc.h
deleted file mode 100644
index 90dfb7a633d1..000000000000
--- a/arch/frv/include/asm/mc146818rtc.h
+++ /dev/null
@@ -1,16 +0,0 @@
-/* mc146818rtc.h: RTC defs
- *
- * Copyright (C) 2005 Red Hat, Inc. All Rights Reserved.
- * Written by David Howells (dhowells@redhat.com)
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#ifndef _ASM_MC146818RTC_H
-#define _ASM_MC146818RTC_H
-
-
-#endif /* _ASM_MC146818RTC_H */
diff --git a/arch/h8300/include/asm/mc146818rtc.h b/arch/h8300/include/asm/mc146818rtc.h
deleted file mode 100644
index ab9d9646d241..000000000000
--- a/arch/h8300/include/asm/mc146818rtc.h
+++ /dev/null
@@ -1,9 +0,0 @@
-/*
- * Machine dependent access functions for RTC registers.
- */
-#ifndef _H8300_MC146818RTC_H
-#define _H8300_MC146818RTC_H
-
-/* empty include file to satisfy the include in genrtc.c/ide-geometry.c */
-
-#endif /* _H8300_MC146818RTC_H */
diff --git a/arch/ia64/include/asm/mc146818rtc.h b/arch/ia64/include/asm/mc146818rtc.h
deleted file mode 100644
index 407787a237ba..000000000000
--- a/arch/ia64/include/asm/mc146818rtc.h
+++ /dev/null
@@ -1,10 +0,0 @@
-#ifndef _ASM_IA64_MC146818RTC_H
-#define _ASM_IA64_MC146818RTC_H
-
-/*
- * Machine dependent access functions for RTC registers.
- */
-
-/* empty include file to satisfy the include in genrtc.c */
-
-#endif /* _ASM_IA64_MC146818RTC_H */
diff --git a/arch/parisc/include/asm/mc146818rtc.h b/arch/parisc/include/asm/mc146818rtc.h
deleted file mode 100644
index adf41631449f..000000000000
--- a/arch/parisc/include/asm/mc146818rtc.h
+++ /dev/null
@@ -1,9 +0,0 @@
-/*
- * Machine dependent access functions for RTC registers.
- */
-#ifndef _ASM_MC146818RTC_H
-#define _ASM_MC146818RTC_H
-
-/* empty include file to satisfy the include in genrtc.c */
-
-#endif /* _ASM_MC146818RTC_H */
diff --git a/arch/sh/include/asm/mc146818rtc.h b/arch/sh/include/asm/mc146818rtc.h
deleted file mode 100644
index 0aee96a97330..000000000000
--- a/arch/sh/include/asm/mc146818rtc.h
+++ /dev/null
@@ -1,7 +0,0 @@
-/*
- * Machine dependent access functions for RTC registers.
- */
-#ifndef _ASM_MC146818RTC_H
-#define _ASM_MC146818RTC_H
-
-#endif /* _ASM_MC146818RTC_H */
-- 
2.7.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PATCH 3/8] char/rtc: remove empty asm/mc146818rtc.h files

[Arnd Bergmann]

Nothing on these architectures ever includes the asm/mc146818rtc.h
file, the drivers that used to do this have been fixed long ago,
and the remaining users are all PC-specific.

This removes the files for good.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/frv/include/asm/mc146818rtc.h    | 16 ----------------
 arch/h8300/include/asm/mc146818rtc.h  |  9 ---------
 arch/ia64/include/asm/mc146818rtc.h   | 10 ----------
 arch/parisc/include/asm/mc146818rtc.h |  9 ---------
 arch/sh/include/asm/mc146818rtc.h     |  7 -------
 5 files changed, 51 deletions(-)
 delete mode 100644 arch/frv/include/asm/mc146818rtc.h
 delete mode 100644 arch/h8300/include/asm/mc146818rtc.h
 delete mode 100644 arch/ia64/include/asm/mc146818rtc.h
 delete mode 100644 arch/parisc/include/asm/mc146818rtc.h
 delete mode 100644 arch/sh/include/asm/mc146818rtc.h

diff --git a/arch/frv/include/asm/mc146818rtc.h b/arch/frv/include/asm/mc146818rtc.h
deleted file mode 100644
index 90dfb7a633d1..000000000000
--- a/arch/frv/include/asm/mc146818rtc.h
+++ /dev/null
@@ -1,16 +0,0 @@
-/* mc146818rtc.h: RTC defs
- *
- * Copyright (C) 2005 Red Hat, Inc. All Rights Reserved.
- * Written by David Howells (dhowells@redhat.com)
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#ifndef _ASM_MC146818RTC_H
-#define _ASM_MC146818RTC_H
-
-
-#endif /* _ASM_MC146818RTC_H */
diff --git a/arch/h8300/include/asm/mc146818rtc.h b/arch/h8300/include/asm/mc146818rtc.h
deleted file mode 100644
index ab9d9646d241..000000000000
--- a/arch/h8300/include/asm/mc146818rtc.h
+++ /dev/null
@@ -1,9 +0,0 @@
-/*
- * Machine dependent access functions for RTC registers.
- */
-#ifndef _H8300_MC146818RTC_H
-#define _H8300_MC146818RTC_H
-
-/* empty include file to satisfy the include in genrtc.c/ide-geometry.c */
-
-#endif /* _H8300_MC146818RTC_H */
diff --git a/arch/ia64/include/asm/mc146818rtc.h b/arch/ia64/include/asm/mc146818rtc.h
deleted file mode 100644
index 407787a237ba..000000000000
--- a/arch/ia64/include/asm/mc146818rtc.h
+++ /dev/null
@@ -1,10 +0,0 @@
-#ifndef _ASM_IA64_MC146818RTC_H
-#define _ASM_IA64_MC146818RTC_H
-
-/*
- * Machine dependent access functions for RTC registers.
- */
-
-/* empty include file to satisfy the include in genrtc.c */
-
-#endif /* _ASM_IA64_MC146818RTC_H */
diff --git a/arch/parisc/include/asm/mc146818rtc.h b/arch/parisc/include/asm/mc146818rtc.h
deleted file mode 100644
index adf41631449f..000000000000
--- a/arch/parisc/include/asm/mc146818rtc.h
+++ /dev/null
@@ -1,9 +0,0 @@
-/*
- * Machine dependent access functions for RTC registers.
- */
-#ifndef _ASM_MC146818RTC_H
-#define _ASM_MC146818RTC_H
-
-/* empty include file to satisfy the include in genrtc.c */
-
-#endif /* _ASM_MC146818RTC_H */
diff --git a/arch/sh/include/asm/mc146818rtc.h b/arch/sh/include/asm/mc146818rtc.h
deleted file mode 100644
index 0aee96a97330..000000000000
--- a/arch/sh/include/asm/mc146818rtc.h
+++ /dev/null
@@ -1,7 +0,0 @@
-/*
- * Machine dependent access functions for RTC registers.
- */
-#ifndef _ASM_MC146818RTC_H
-#define _ASM_MC146818RTC_H
-
-#endif /* _ASM_MC146818RTC_H */
-- 
2.7.0

Re: [PATCH 3/8] char/rtc: remove empty asm/mc146818rtc.h files

[Alexandre Belloni]

On 26/04/2016 at 23:44:07 +0200, Arnd Bergmann wrote :
> Nothing on these architectures ever includes the asm/mc146818rtc.h
> file, the drivers that used to do this have been fixed long ago,
> and the remaining users are all PC-specific.
> 
> This removes the files for good.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

> ---
>  arch/frv/include/asm/mc146818rtc.h    | 16 ----------------
>  arch/h8300/include/asm/mc146818rtc.h  |  9 ---------
>  arch/ia64/include/asm/mc146818rtc.h   | 10 ----------
>  arch/parisc/include/asm/mc146818rtc.h |  9 ---------
>  arch/sh/include/asm/mc146818rtc.h     |  7 -------
>  5 files changed, 51 deletions(-)
>  delete mode 100644 arch/frv/include/asm/mc146818rtc.h
>  delete mode 100644 arch/h8300/include/asm/mc146818rtc.h
>  delete mode 100644 arch/ia64/include/asm/mc146818rtc.h
>  delete mode 100644 arch/parisc/include/asm/mc146818rtc.h
>  delete mode 100644 arch/sh/include/asm/mc146818rtc.h
> 
> diff --git a/arch/frv/include/asm/mc146818rtc.h b/arch/frv/include/asm/mc146818rtc.h
> deleted file mode 100644
> index 90dfb7a633d1..000000000000
> --- a/arch/frv/include/asm/mc146818rtc.h
> +++ /dev/null
> @@ -1,16 +0,0 @@
> -/* mc146818rtc.h: RTC defs
> - *
> - * Copyright (C) 2005 Red Hat, Inc. All Rights Reserved.
> - * Written by David Howells (dhowells@redhat.com)
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License
> - * as published by the Free Software Foundation; either version
> - * 2 of the License, or (at your option) any later version.
> - */
> -
> -#ifndef _ASM_MC146818RTC_H
> -#define _ASM_MC146818RTC_H
> -
> -
> -#endif /* _ASM_MC146818RTC_H */
> diff --git a/arch/h8300/include/asm/mc146818rtc.h b/arch/h8300/include/asm/mc146818rtc.h
> deleted file mode 100644
> index ab9d9646d241..000000000000
> --- a/arch/h8300/include/asm/mc146818rtc.h
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -/*
> - * Machine dependent access functions for RTC registers.
> - */
> -#ifndef _H8300_MC146818RTC_H
> -#define _H8300_MC146818RTC_H
> -
> -/* empty include file to satisfy the include in genrtc.c/ide-geometry.c */
> -
> -#endif /* _H8300_MC146818RTC_H */
> diff --git a/arch/ia64/include/asm/mc146818rtc.h b/arch/ia64/include/asm/mc146818rtc.h
> deleted file mode 100644
> index 407787a237ba..000000000000
> --- a/arch/ia64/include/asm/mc146818rtc.h
> +++ /dev/null
> @@ -1,10 +0,0 @@
> -#ifndef _ASM_IA64_MC146818RTC_H
> -#define _ASM_IA64_MC146818RTC_H
> -
> -/*
> - * Machine dependent access functions for RTC registers.
> - */
> -
> -/* empty include file to satisfy the include in genrtc.c */
> -
> -#endif /* _ASM_IA64_MC146818RTC_H */
> diff --git a/arch/parisc/include/asm/mc146818rtc.h b/arch/parisc/include/asm/mc146818rtc.h
> deleted file mode 100644
> index adf41631449f..000000000000
> --- a/arch/parisc/include/asm/mc146818rtc.h
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -/*
> - * Machine dependent access functions for RTC registers.
> - */
> -#ifndef _ASM_MC146818RTC_H
> -#define _ASM_MC146818RTC_H
> -
> -/* empty include file to satisfy the include in genrtc.c */
> -
> -#endif /* _ASM_MC146818RTC_H */
> diff --git a/arch/sh/include/asm/mc146818rtc.h b/arch/sh/include/asm/mc146818rtc.h
> deleted file mode 100644
> index 0aee96a97330..000000000000
> --- a/arch/sh/include/asm/mc146818rtc.h
> +++ /dev/null
> @@ -1,7 +0,0 @@
> -/*
> - * Machine dependent access functions for RTC registers.
> - */
> -#ifndef _ASM_MC146818RTC_H
> -#define _ASM_MC146818RTC_H
> -
> -#endif /* _ASM_MC146818RTC_H */
> -- 
> 2.7.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[rtc-linux] Re: [PATCH 3/8] char/rtc: remove empty asm/mc146818rtc.h files

[Alexandre Belloni]

On 26/04/2016 at 23:44:07 +0200, Arnd Bergmann wrote :
> Nothing on these architectures ever includes the asm/mc146818rtc.h
> file, the drivers that used to do this have been fixed long ago,
> and the remaining users are all PC-specific.
> 
> This removes the files for good.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

> ---
>  arch/frv/include/asm/mc146818rtc.h    | 16 ----------------
>  arch/h8300/include/asm/mc146818rtc.h  |  9 ---------
>  arch/ia64/include/asm/mc146818rtc.h   | 10 ----------
>  arch/parisc/include/asm/mc146818rtc.h |  9 ---------
>  arch/sh/include/asm/mc146818rtc.h     |  7 -------
>  5 files changed, 51 deletions(-)
>  delete mode 100644 arch/frv/include/asm/mc146818rtc.h
>  delete mode 100644 arch/h8300/include/asm/mc146818rtc.h
>  delete mode 100644 arch/ia64/include/asm/mc146818rtc.h
>  delete mode 100644 arch/parisc/include/asm/mc146818rtc.h
>  delete mode 100644 arch/sh/include/asm/mc146818rtc.h
> 
> diff --git a/arch/frv/include/asm/mc146818rtc.h b/arch/frv/include/asm/mc146818rtc.h
> deleted file mode 100644
> index 90dfb7a633d1..000000000000
> --- a/arch/frv/include/asm/mc146818rtc.h
> +++ /dev/null
> @@ -1,16 +0,0 @@
> -/* mc146818rtc.h: RTC defs
> - *
> - * Copyright (C) 2005 Red Hat, Inc. All Rights Reserved.
> - * Written by David Howells (dhowells@redhat.com)
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License
> - * as published by the Free Software Foundation; either version
> - * 2 of the License, or (at your option) any later version.
> - */
> -
> -#ifndef _ASM_MC146818RTC_H
> -#define _ASM_MC146818RTC_H
> -
> -
> -#endif /* _ASM_MC146818RTC_H */
> diff --git a/arch/h8300/include/asm/mc146818rtc.h b/arch/h8300/include/asm/mc146818rtc.h
> deleted file mode 100644
> index ab9d9646d241..000000000000
> --- a/arch/h8300/include/asm/mc146818rtc.h
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -/*
> - * Machine dependent access functions for RTC registers.
> - */
> -#ifndef _H8300_MC146818RTC_H
> -#define _H8300_MC146818RTC_H
> -
> -/* empty include file to satisfy the include in genrtc.c/ide-geometry.c */
> -
> -#endif /* _H8300_MC146818RTC_H */
> diff --git a/arch/ia64/include/asm/mc146818rtc.h b/arch/ia64/include/asm/mc146818rtc.h
> deleted file mode 100644
> index 407787a237ba..000000000000
> --- a/arch/ia64/include/asm/mc146818rtc.h
> +++ /dev/null
> @@ -1,10 +0,0 @@
> -#ifndef _ASM_IA64_MC146818RTC_H
> -#define _ASM_IA64_MC146818RTC_H
> -
> -/*
> - * Machine dependent access functions for RTC registers.
> - */
> -
> -/* empty include file to satisfy the include in genrtc.c */
> -
> -#endif /* _ASM_IA64_MC146818RTC_H */
> diff --git a/arch/parisc/include/asm/mc146818rtc.h b/arch/parisc/include/asm/mc146818rtc.h
> deleted file mode 100644
> index adf41631449f..000000000000
> --- a/arch/parisc/include/asm/mc146818rtc.h
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -/*
> - * Machine dependent access functions for RTC registers.
> - */
> -#ifndef _ASM_MC146818RTC_H
> -#define _ASM_MC146818RTC_H
> -
> -/* empty include file to satisfy the include in genrtc.c */
> -
> -#endif /* _ASM_MC146818RTC_H */
> diff --git a/arch/sh/include/asm/mc146818rtc.h b/arch/sh/include/asm/mc146818rtc.h
> deleted file mode 100644
> index 0aee96a97330..000000000000
> --- a/arch/sh/include/asm/mc146818rtc.h
> +++ /dev/null
> @@ -1,7 +0,0 @@
> -/*
> - * Machine dependent access functions for RTC registers.
> - */
> -#ifndef _ASM_MC146818RTC_H
> -#define _ASM_MC146818RTC_H
> -
> -#endif /* _ASM_MC146818RTC_H */
> -- 
> 2.7.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 3/8] char/rtc: remove empty asm/mc146818rtc.h files

[Alexandre Belloni]

On 26/04/2016 at 23:44:07 +0200, Arnd Bergmann wrote :
> Nothing on these architectures ever includes the asm/mc146818rtc.h
> file, the drivers that used to do this have been fixed long ago,
> and the remaining users are all PC-specific.
> 
> This removes the files for good.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

> ---
>  arch/frv/include/asm/mc146818rtc.h    | 16 ----------------
>  arch/h8300/include/asm/mc146818rtc.h  |  9 ---------
>  arch/ia64/include/asm/mc146818rtc.h   | 10 ----------
>  arch/parisc/include/asm/mc146818rtc.h |  9 ---------
>  arch/sh/include/asm/mc146818rtc.h     |  7 -------
>  5 files changed, 51 deletions(-)
>  delete mode 100644 arch/frv/include/asm/mc146818rtc.h
>  delete mode 100644 arch/h8300/include/asm/mc146818rtc.h
>  delete mode 100644 arch/ia64/include/asm/mc146818rtc.h
>  delete mode 100644 arch/parisc/include/asm/mc146818rtc.h
>  delete mode 100644 arch/sh/include/asm/mc146818rtc.h
> 
> diff --git a/arch/frv/include/asm/mc146818rtc.h b/arch/frv/include/asm/mc146818rtc.h
> deleted file mode 100644
> index 90dfb7a633d1..000000000000
> --- a/arch/frv/include/asm/mc146818rtc.h
> +++ /dev/null
> @@ -1,16 +0,0 @@
> -/* mc146818rtc.h: RTC defs
> - *
> - * Copyright (C) 2005 Red Hat, Inc. All Rights Reserved.
> - * Written by David Howells (dhowells@redhat.com)
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License
> - * as published by the Free Software Foundation; either version
> - * 2 of the License, or (at your option) any later version.
> - */
> -
> -#ifndef _ASM_MC146818RTC_H
> -#define _ASM_MC146818RTC_H
> -
> -
> -#endif /* _ASM_MC146818RTC_H */
> diff --git a/arch/h8300/include/asm/mc146818rtc.h b/arch/h8300/include/asm/mc146818rtc.h
> deleted file mode 100644
> index ab9d9646d241..000000000000
> --- a/arch/h8300/include/asm/mc146818rtc.h
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -/*
> - * Machine dependent access functions for RTC registers.
> - */
> -#ifndef _H8300_MC146818RTC_H
> -#define _H8300_MC146818RTC_H
> -
> -/* empty include file to satisfy the include in genrtc.c/ide-geometry.c */
> -
> -#endif /* _H8300_MC146818RTC_H */
> diff --git a/arch/ia64/include/asm/mc146818rtc.h b/arch/ia64/include/asm/mc146818rtc.h
> deleted file mode 100644
> index 407787a237ba..000000000000
> --- a/arch/ia64/include/asm/mc146818rtc.h
> +++ /dev/null
> @@ -1,10 +0,0 @@
> -#ifndef _ASM_IA64_MC146818RTC_H
> -#define _ASM_IA64_MC146818RTC_H
> -
> -/*
> - * Machine dependent access functions for RTC registers.
> - */
> -
> -/* empty include file to satisfy the include in genrtc.c */
> -
> -#endif /* _ASM_IA64_MC146818RTC_H */
> diff --git a/arch/parisc/include/asm/mc146818rtc.h b/arch/parisc/include/asm/mc146818rtc.h
> deleted file mode 100644
> index adf41631449f..000000000000
> --- a/arch/parisc/include/asm/mc146818rtc.h
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -/*
> - * Machine dependent access functions for RTC registers.
> - */
> -#ifndef _ASM_MC146818RTC_H
> -#define _ASM_MC146818RTC_H
> -
> -/* empty include file to satisfy the include in genrtc.c */
> -
> -#endif /* _ASM_MC146818RTC_H */
> diff --git a/arch/sh/include/asm/mc146818rtc.h b/arch/sh/include/asm/mc146818rtc.h
> deleted file mode 100644
> index 0aee96a97330..000000000000
> --- a/arch/sh/include/asm/mc146818rtc.h
> +++ /dev/null
> @@ -1,7 +0,0 @@
> -/*
> - * Machine dependent access functions for RTC registers.
> - */
> -#ifndef _ASM_MC146818RTC_H
> -#define _ASM_MC146818RTC_H
> -
> -#endif /* _ASM_MC146818RTC_H */
> -- 
> 2.7.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 4/8] char/rtc: move mc146818rtc code out of asm-generic/rtc.h

[Arnd Bergmann]

Drivers should not really include stuff from asm-generic directly,
and the PC-style cmos rtc driver does this in order to reuse the
mc146818 implementation of get_rtc_time/set_rtc_time rather than
the architecture specific one for the architecture it gets built for.

To make it more obvious what is going on, this moves and renames the
two functions into include/linux/mc146818rtc.h, which holds the
other mc146818 specific code. Ideally it would be in a .c file,
but that would require extra infrastructure as the functions are
called by multiple drivers with conflicting dependencies.

With this change, the asm-generic/rtc.h header also becomes much
more generic, so it can be reused more easily across any architecture
that still relies on the genrtc driver.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/rtc/rtc-cmos.c      |  12 +--
 include/asm-generic/rtc.h   | 206 ++------------------------------------------
 include/linux/mc146818rtc.h | 194 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 205 insertions(+), 207 deletions(-)

diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 84fb541038be..c7993f18edfa 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -43,7 +43,7 @@
 #include <linux/of_platform.h>
 
 /* this is for "generic access to PC-style RTC" using CMOS_READ/CMOS_WRITE */
-#include <asm-generic/rtc.h>
+#include <linux/mc146818rtc.h>
 
 struct cmos_rtc {
 	struct rtc_device	*rtc;
@@ -190,10 +190,10 @@ static inline void cmos_write_bank2(unsigned char val, unsigned char addr)
 static int cmos_read_time(struct device *dev, struct rtc_time *t)
 {
 	/* REVISIT:  if the clock has a "century" register, use
-	 * that instead of the heuristic in get_rtc_time().
+	 * that instead of the heuristic in mc146818_get_time().
 	 * That'll make Y3K compatility (year > 2070) easy!
 	 */
-	get_rtc_time(t);
+	mc146818_get_time(t);
 	return 0;
 }
 
@@ -205,7 +205,7 @@ static int cmos_set_time(struct device *dev, struct rtc_time *t)
 	 * takes effect exactly 500ms after we write the register.
 	 * (Also queueing and other delays before we get this far.)
 	 */
-	return set_rtc_time(t);
+	return mc146818_set_time(t);
 }
 
 static int cmos_read_alarm(struct device *dev, struct rtc_wkalrm *t)
@@ -1142,14 +1142,14 @@ static __init void cmos_of_init(struct platform_device *pdev)
 	if (val)
 		CMOS_WRITE(be32_to_cpup(val), RTC_FREQ_SELECT);
 
-	get_rtc_time(&time);
+	cmos_read_time(&pdev->dev, &time);
 	ret = rtc_valid_tm(&time);
 	if (ret) {
 		struct rtc_time def_time = {
 			.tm_year = 1,
 			.tm_mday = 1,
 		};
-		set_rtc_time(&def_time);
+		cmos_set_time(&pdev->dev, &def_time);
 	}
 }
 #else
diff --git a/include/asm-generic/rtc.h b/include/asm-generic/rtc.h
index 4e3b6558331e..4fcff22cd707 100644
--- a/include/asm-generic/rtc.h
+++ b/include/asm-generic/rtc.h
@@ -12,12 +12,12 @@
 #ifndef __ASM_RTC_H__
 #define __ASM_RTC_H__
 
-#include <linux/mc146818rtc.h>
 #include <linux/rtc.h>
-#include <linux/bcd.h>
-#include <linux/delay.h>
-#ifdef CONFIG_ACPI
-#include <linux/acpi.h>
+
+#ifndef get_rtc_time
+#include <linux/mc146818rtc.h>
+#define get_rtc_time mc146818_get_time
+#define set_rtc_time mc146818_set_time
 #endif
 
 #define RTC_PIE 0x40		/* periodic interrupt enable */
@@ -31,202 +31,6 @@
 #define RTC_24H 0x02		/* 24 hour mode - else hours bit 7 means pm */
 #define RTC_DST_EN 0x01	        /* auto switch DST - works f. USA only */
 
-/*
- * Returns true if a clock update is in progress
- */
-static inline unsigned char rtc_is_updating(void)
-{
-	unsigned char uip;
-	unsigned long flags;
-
-	spin_lock_irqsave(&rtc_lock, flags);
-	uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
-	spin_unlock_irqrestore(&rtc_lock, flags);
-	return uip;
-}
-
-static inline unsigned int __get_rtc_time(struct rtc_time *time)
-{
-	unsigned char ctrl;
-	unsigned long flags;
-	unsigned char century = 0;
-
-#ifdef CONFIG_MACH_DECSTATION
-	unsigned int real_year;
-#endif
-
-	/*
-	 * read RTC once any update in progress is done. The update
-	 * can take just over 2ms. We wait 20ms. There is no need to
-	 * to poll-wait (up to 1s - eeccch) for the falling edge of RTC_UIP.
-	 * If you need to know *exactly* when a second has started, enable
-	 * periodic update complete interrupts, (via ioctl) and then 
-	 * immediately read /dev/rtc which will block until you get the IRQ.
-	 * Once the read clears, read the RTC time (again via ioctl). Easy.
-	 */
-	if (rtc_is_updating())
-		mdelay(20);
-
-	/*
-	 * Only the values that we read from the RTC are set. We leave
-	 * tm_wday, tm_yday and tm_isdst untouched. Even though the
-	 * RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
-	 * by the RTC when initially set to a non-zero value.
-	 */
-	spin_lock_irqsave(&rtc_lock, flags);
-	time->tm_sec = CMOS_READ(RTC_SECONDS);
-	time->tm_min = CMOS_READ(RTC_MINUTES);
-	time->tm_hour = CMOS_READ(RTC_HOURS);
-	time->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH);
-	time->tm_mon = CMOS_READ(RTC_MONTH);
-	time->tm_year = CMOS_READ(RTC_YEAR);
-#ifdef CONFIG_MACH_DECSTATION
-	real_year = CMOS_READ(RTC_DEC_YEAR);
-#endif
-#ifdef CONFIG_ACPI
-	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
-	    acpi_gbl_FADT.century)
-		century = CMOS_READ(acpi_gbl_FADT.century);
-#endif
-	ctrl = CMOS_READ(RTC_CONTROL);
-	spin_unlock_irqrestore(&rtc_lock, flags);
-
-	if (!(ctrl & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
-	{
-		time->tm_sec = bcd2bin(time->tm_sec);
-		time->tm_min = bcd2bin(time->tm_min);
-		time->tm_hour = bcd2bin(time->tm_hour);
-		time->tm_mday = bcd2bin(time->tm_mday);
-		time->tm_mon = bcd2bin(time->tm_mon);
-		time->tm_year = bcd2bin(time->tm_year);
-		century = bcd2bin(century);
-	}
-
-#ifdef CONFIG_MACH_DECSTATION
-	time->tm_year += real_year - 72;
-#endif
-
-	if (century)
-		time->tm_year += (century - 19) * 100;
-
-	/*
-	 * Account for differences between how the RTC uses the values
-	 * and how they are defined in a struct rtc_time;
-	 */
-	if (time->tm_year <= 69)
-		time->tm_year += 100;
-
-	time->tm_mon--;
-
-	return RTC_24H;
-}
-
-#ifndef get_rtc_time
-#define get_rtc_time	__get_rtc_time
-#endif
-
-/* Set the current date and time in the real time clock. */
-static inline int __set_rtc_time(struct rtc_time *time)
-{
-	unsigned long flags;
-	unsigned char mon, day, hrs, min, sec;
-	unsigned char save_control, save_freq_select;
-	unsigned int yrs;
-#ifdef CONFIG_MACH_DECSTATION
-	unsigned int real_yrs, leap_yr;
-#endif
-	unsigned char century = 0;
-
-	yrs = time->tm_year;
-	mon = time->tm_mon + 1;   /* tm_mon starts at zero */
-	day = time->tm_mday;
-	hrs = time->tm_hour;
-	min = time->tm_min;
-	sec = time->tm_sec;
-
-	if (yrs > 255)	/* They are unsigned */
-		return -EINVAL;
-
-	spin_lock_irqsave(&rtc_lock, flags);
-#ifdef CONFIG_MACH_DECSTATION
-	real_yrs = yrs;
-	leap_yr = ((!((yrs + 1900) % 4) && ((yrs + 1900) % 100)) ||
-			!((yrs + 1900) % 400));
-	yrs = 72;
-
-	/*
-	 * We want to keep the year set to 73 until March
-	 * for non-leap years, so that Feb, 29th is handled
-	 * correctly.
-	 */
-	if (!leap_yr && mon < 3) {
-		real_yrs--;
-		yrs = 73;
-	}
-#endif
-
-#ifdef CONFIG_ACPI
-	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
-	    acpi_gbl_FADT.century) {
-		century = (yrs + 1900) / 100;
-		yrs %= 100;
-	}
-#endif
-
-	/* These limits and adjustments are independent of
-	 * whether the chip is in binary mode or not.
-	 */
-	if (yrs > 169) {
-		spin_unlock_irqrestore(&rtc_lock, flags);
-		return -EINVAL;
-	}
-
-	if (yrs >= 100)
-		yrs -= 100;
-
-	if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY)
-	    || RTC_ALWAYS_BCD) {
-		sec = bin2bcd(sec);
-		min = bin2bcd(min);
-		hrs = bin2bcd(hrs);
-		day = bin2bcd(day);
-		mon = bin2bcd(mon);
-		yrs = bin2bcd(yrs);
-		century = bin2bcd(century);
-	}
-
-	save_control = CMOS_READ(RTC_CONTROL);
-	CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
-	save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
-	CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
-
-#ifdef CONFIG_MACH_DECSTATION
-	CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
-#endif
-	CMOS_WRITE(yrs, RTC_YEAR);
-	CMOS_WRITE(mon, RTC_MONTH);
-	CMOS_WRITE(day, RTC_DAY_OF_MONTH);
-	CMOS_WRITE(hrs, RTC_HOURS);
-	CMOS_WRITE(min, RTC_MINUTES);
-	CMOS_WRITE(sec, RTC_SECONDS);
-#ifdef CONFIG_ACPI
-	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
-	    acpi_gbl_FADT.century)
-		CMOS_WRITE(century, acpi_gbl_FADT.century);
-#endif
-
-	CMOS_WRITE(save_control, RTC_CONTROL);
-	CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
-
-	spin_unlock_irqrestore(&rtc_lock, flags);
-
-	return 0;
-}
-
-#ifndef set_rtc_time
-#define set_rtc_time	__set_rtc_time
-#endif
-
 static inline unsigned int get_rtc_ss(void)
 {
 	struct rtc_time h;
diff --git a/include/linux/mc146818rtc.h b/include/linux/mc146818rtc.h
index 433e0c74d643..e9e346b37846 100644
--- a/include/linux/mc146818rtc.h
+++ b/include/linux/mc146818rtc.h
@@ -14,6 +14,12 @@
 #include <asm/io.h>
 #include <linux/rtc.h>			/* get the user-level API */
 #include <asm/mc146818rtc.h>		/* register access macros */
+#include <linux/bcd.h>
+#include <linux/delay.h>
+
+#ifdef CONFIG_ACPI
+#include <linux/acpi.h>
+#endif
 
 #ifdef __KERNEL__
 #include <linux/spinlock.h>		/* spinlock_t */
@@ -120,4 +126,192 @@ struct cmos_rtc_board_info {
 #define RTC_IO_EXTENT_USED      RTC_IO_EXTENT
 #endif /* ARCH_RTC_LOCATION */
 
+/*
+ * Returns true if a clock update is in progress
+ */
+static inline unsigned char mc146818_is_updating(void)
+{
+	unsigned char uip;
+	unsigned long flags;
+
+	spin_lock_irqsave(&rtc_lock, flags);
+	uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
+	spin_unlock_irqrestore(&rtc_lock, flags);
+	return uip;
+}
+
+static inline unsigned int mc146818_get_time(struct rtc_time *time)
+{
+	unsigned char ctrl;
+	unsigned long flags;
+	unsigned char century = 0;
+
+#ifdef CONFIG_MACH_DECSTATION
+	unsigned int real_year;
+#endif
+
+	/*
+	 * read RTC once any update in progress is done. The update
+	 * can take just over 2ms. We wait 20ms. There is no need to
+	 * to poll-wait (up to 1s - eeccch) for the falling edge of RTC_UIP.
+	 * If you need to know *exactly* when a second has started, enable
+	 * periodic update complete interrupts, (via ioctl) and then 
+	 * immediately read /dev/rtc which will block until you get the IRQ.
+	 * Once the read clears, read the RTC time (again via ioctl). Easy.
+	 */
+	if (mc146818_is_updating())
+		mdelay(20);
+
+	/*
+	 * Only the values that we read from the RTC are set. We leave
+	 * tm_wday, tm_yday and tm_isdst untouched. Even though the
+	 * RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
+	 * by the RTC when initially set to a non-zero value.
+	 */
+	spin_lock_irqsave(&rtc_lock, flags);
+	time->tm_sec = CMOS_READ(RTC_SECONDS);
+	time->tm_min = CMOS_READ(RTC_MINUTES);
+	time->tm_hour = CMOS_READ(RTC_HOURS);
+	time->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH);
+	time->tm_mon = CMOS_READ(RTC_MONTH);
+	time->tm_year = CMOS_READ(RTC_YEAR);
+#ifdef CONFIG_MACH_DECSTATION
+	real_year = CMOS_READ(RTC_DEC_YEAR);
+#endif
+#ifdef CONFIG_ACPI
+	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
+	    acpi_gbl_FADT.century)
+		century = CMOS_READ(acpi_gbl_FADT.century);
+#endif
+	ctrl = CMOS_READ(RTC_CONTROL);
+	spin_unlock_irqrestore(&rtc_lock, flags);
+
+	if (!(ctrl & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
+	{
+		time->tm_sec = bcd2bin(time->tm_sec);
+		time->tm_min = bcd2bin(time->tm_min);
+		time->tm_hour = bcd2bin(time->tm_hour);
+		time->tm_mday = bcd2bin(time->tm_mday);
+		time->tm_mon = bcd2bin(time->tm_mon);
+		time->tm_year = bcd2bin(time->tm_year);
+		century = bcd2bin(century);
+	}
+
+#ifdef CONFIG_MACH_DECSTATION
+	time->tm_year += real_year - 72;
+#endif
+
+	if (century)
+		time->tm_year += (century - 19) * 100;
+
+	/*
+	 * Account for differences between how the RTC uses the values
+	 * and how they are defined in a struct rtc_time;
+	 */
+	if (time->tm_year <= 69)
+		time->tm_year += 100;
+
+	time->tm_mon--;
+
+	return RTC_24H;
+}
+
+/* Set the current date and time in the real time clock. */
+static inline int mc146818_set_time(struct rtc_time *time)
+{
+	unsigned long flags;
+	unsigned char mon, day, hrs, min, sec;
+	unsigned char save_control, save_freq_select;
+	unsigned int yrs;
+#ifdef CONFIG_MACH_DECSTATION
+	unsigned int real_yrs, leap_yr;
+#endif
+	unsigned char century = 0;
+
+	yrs = time->tm_year;
+	mon = time->tm_mon + 1;   /* tm_mon starts at zero */
+	day = time->tm_mday;
+	hrs = time->tm_hour;
+	min = time->tm_min;
+	sec = time->tm_sec;
+
+	if (yrs > 255)	/* They are unsigned */
+		return -EINVAL;
+
+	spin_lock_irqsave(&rtc_lock, flags);
+#ifdef CONFIG_MACH_DECSTATION
+	real_yrs = yrs;
+	leap_yr = ((!((yrs + 1900) % 4) && ((yrs + 1900) % 100)) ||
+			!((yrs + 1900) % 400));
+	yrs = 72;
+
+	/*
+	 * We want to keep the year set to 73 until March
+	 * for non-leap years, so that Feb, 29th is handled
+	 * correctly.
+	 */
+	if (!leap_yr && mon < 3) {
+		real_yrs--;
+		yrs = 73;
+	}
+#endif
+
+#ifdef CONFIG_ACPI
+	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
+	    acpi_gbl_FADT.century) {
+		century = (yrs + 1900) / 100;
+		yrs %= 100;
+	}
+#endif
+
+	/* These limits and adjustments are independent of
+	 * whether the chip is in binary mode or not.
+	 */
+	if (yrs > 169) {
+		spin_unlock_irqrestore(&rtc_lock, flags);
+		return -EINVAL;
+	}
+
+	if (yrs >= 100)
+		yrs -= 100;
+
+	if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY)
+	    || RTC_ALWAYS_BCD) {
+		sec = bin2bcd(sec);
+		min = bin2bcd(min);
+		hrs = bin2bcd(hrs);
+		day = bin2bcd(day);
+		mon = bin2bcd(mon);
+		yrs = bin2bcd(yrs);
+		century = bin2bcd(century);
+	}
+
+	save_control = CMOS_READ(RTC_CONTROL);
+	CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
+	save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
+	CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
+
+#ifdef CONFIG_MACH_DECSTATION
+	CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
+#endif
+	CMOS_WRITE(yrs, RTC_YEAR);
+	CMOS_WRITE(mon, RTC_MONTH);
+	CMOS_WRITE(day, RTC_DAY_OF_MONTH);
+	CMOS_WRITE(hrs, RTC_HOURS);
+	CMOS_WRITE(min, RTC_MINUTES);
+	CMOS_WRITE(sec, RTC_SECONDS);
+#ifdef CONFIG_ACPI
+	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
+	    acpi_gbl_FADT.century)
+		CMOS_WRITE(century, acpi_gbl_FADT.century);
+#endif
+
+	CMOS_WRITE(save_control, RTC_CONTROL);
+	CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
+
+	spin_unlock_irqrestore(&rtc_lock, flags);
+
+	return 0;
+}
+
 #endif /* _MC146818RTC_H */
-- 
2.7.0

[rtc-linux] [PATCH 4/8] char/rtc: move mc146818rtc code out of asm-generic/rtc.h

[Arnd Bergmann]

Drivers should not really include stuff from asm-generic directly,
and the PC-style cmos rtc driver does this in order to reuse the
mc146818 implementation of get_rtc_time/set_rtc_time rather than
the architecture specific one for the architecture it gets built for.

To make it more obvious what is going on, this moves and renames the
two functions into include/linux/mc146818rtc.h, which holds the
other mc146818 specific code. Ideally it would be in a .c file,
but that would require extra infrastructure as the functions are
called by multiple drivers with conflicting dependencies.

With this change, the asm-generic/rtc.h header also becomes much
more generic, so it can be reused more easily across any architecture
that still relies on the genrtc driver.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/rtc/rtc-cmos.c      |  12 +--
 include/asm-generic/rtc.h   | 206 ++------------------------------------------
 include/linux/mc146818rtc.h | 194 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 205 insertions(+), 207 deletions(-)

diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 84fb541038be..c7993f18edfa 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -43,7 +43,7 @@
 #include <linux/of_platform.h>
 
 /* this is for "generic access to PC-style RTC" using CMOS_READ/CMOS_WRITE */
-#include <asm-generic/rtc.h>
+#include <linux/mc146818rtc.h>
 
 struct cmos_rtc {
 	struct rtc_device	*rtc;
@@ -190,10 +190,10 @@ static inline void cmos_write_bank2(unsigned char val, unsigned char addr)
 static int cmos_read_time(struct device *dev, struct rtc_time *t)
 {
 	/* REVISIT:  if the clock has a "century" register, use
-	 * that instead of the heuristic in get_rtc_time().
+	 * that instead of the heuristic in mc146818_get_time().
 	 * That'll make Y3K compatility (year > 2070) easy!
 	 */
-	get_rtc_time(t);
+	mc146818_get_time(t);
 	return 0;
 }
 
@@ -205,7 +205,7 @@ static int cmos_set_time(struct device *dev, struct rtc_time *t)
 	 * takes effect exactly 500ms after we write the register.
 	 * (Also queueing and other delays before we get this far.)
 	 */
-	return set_rtc_time(t);
+	return mc146818_set_time(t);
 }
 
 static int cmos_read_alarm(struct device *dev, struct rtc_wkalrm *t)
@@ -1142,14 +1142,14 @@ static __init void cmos_of_init(struct platform_device *pdev)
 	if (val)
 		CMOS_WRITE(be32_to_cpup(val), RTC_FREQ_SELECT);
 
-	get_rtc_time(&time);
+	cmos_read_time(&pdev->dev, &time);
 	ret = rtc_valid_tm(&time);
 	if (ret) {
 		struct rtc_time def_time = {
 			.tm_year = 1,
 			.tm_mday = 1,
 		};
-		set_rtc_time(&def_time);
+		cmos_set_time(&pdev->dev, &def_time);
 	}
 }
 #else
diff --git a/include/asm-generic/rtc.h b/include/asm-generic/rtc.h
index 4e3b6558331e..4fcff22cd707 100644
--- a/include/asm-generic/rtc.h
+++ b/include/asm-generic/rtc.h
@@ -12,12 +12,12 @@
 #ifndef __ASM_RTC_H__
 #define __ASM_RTC_H__
 
-#include <linux/mc146818rtc.h>
 #include <linux/rtc.h>
-#include <linux/bcd.h>
-#include <linux/delay.h>
-#ifdef CONFIG_ACPI
-#include <linux/acpi.h>
+
+#ifndef get_rtc_time
+#include <linux/mc146818rtc.h>
+#define get_rtc_time mc146818_get_time
+#define set_rtc_time mc146818_set_time
 #endif
 
 #define RTC_PIE 0x40		/* periodic interrupt enable */
@@ -31,202 +31,6 @@
 #define RTC_24H 0x02		/* 24 hour mode - else hours bit 7 means pm */
 #define RTC_DST_EN 0x01	        /* auto switch DST - works f. USA only */
 
-/*
- * Returns true if a clock update is in progress
- */
-static inline unsigned char rtc_is_updating(void)
-{
-	unsigned char uip;
-	unsigned long flags;
-
-	spin_lock_irqsave(&rtc_lock, flags);
-	uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
-	spin_unlock_irqrestore(&rtc_lock, flags);
-	return uip;
-}
-
-static inline unsigned int __get_rtc_time(struct rtc_time *time)
-{
-	unsigned char ctrl;
-	unsigned long flags;
-	unsigned char century = 0;
-
-#ifdef CONFIG_MACH_DECSTATION
-	unsigned int real_year;
-#endif
-
-	/*
-	 * read RTC once any update in progress is done. The update
-	 * can take just over 2ms. We wait 20ms. There is no need to
-	 * to poll-wait (up to 1s - eeccch) for the falling edge of RTC_UIP.
-	 * If you need to know *exactly* when a second has started, enable
-	 * periodic update complete interrupts, (via ioctl) and then 
-	 * immediately read /dev/rtc which will block until you get the IRQ.
-	 * Once the read clears, read the RTC time (again via ioctl). Easy.
-	 */
-	if (rtc_is_updating())
-		mdelay(20);
-
-	/*
-	 * Only the values that we read from the RTC are set. We leave
-	 * tm_wday, tm_yday and tm_isdst untouched. Even though the
-	 * RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
-	 * by the RTC when initially set to a non-zero value.
-	 */
-	spin_lock_irqsave(&rtc_lock, flags);
-	time->tm_sec = CMOS_READ(RTC_SECONDS);
-	time->tm_min = CMOS_READ(RTC_MINUTES);
-	time->tm_hour = CMOS_READ(RTC_HOURS);
-	time->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH);
-	time->tm_mon = CMOS_READ(RTC_MONTH);
-	time->tm_year = CMOS_READ(RTC_YEAR);
-#ifdef CONFIG_MACH_DECSTATION
-	real_year = CMOS_READ(RTC_DEC_YEAR);
-#endif
-#ifdef CONFIG_ACPI
-	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
-	    acpi_gbl_FADT.century)
-		century = CMOS_READ(acpi_gbl_FADT.century);
-#endif
-	ctrl = CMOS_READ(RTC_CONTROL);
-	spin_unlock_irqrestore(&rtc_lock, flags);
-
-	if (!(ctrl & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
-	{
-		time->tm_sec = bcd2bin(time->tm_sec);
-		time->tm_min = bcd2bin(time->tm_min);
-		time->tm_hour = bcd2bin(time->tm_hour);
-		time->tm_mday = bcd2bin(time->tm_mday);
-		time->tm_mon = bcd2bin(time->tm_mon);
-		time->tm_year = bcd2bin(time->tm_year);
-		century = bcd2bin(century);
-	}
-
-#ifdef CONFIG_MACH_DECSTATION
-	time->tm_year += real_year - 72;
-#endif
-
-	if (century)
-		time->tm_year += (century - 19) * 100;
-
-	/*
-	 * Account for differences between how the RTC uses the values
-	 * and how they are defined in a struct rtc_time;
-	 */
-	if (time->tm_year <= 69)
-		time->tm_year += 100;
-
-	time->tm_mon--;
-
-	return RTC_24H;
-}
-
-#ifndef get_rtc_time
-#define get_rtc_time	__get_rtc_time
-#endif
-
-/* Set the current date and time in the real time clock. */
-static inline int __set_rtc_time(struct rtc_time *time)
-{
-	unsigned long flags;
-	unsigned char mon, day, hrs, min, sec;
-	unsigned char save_control, save_freq_select;
-	unsigned int yrs;
-#ifdef CONFIG_MACH_DECSTATION
-	unsigned int real_yrs, leap_yr;
-#endif
-	unsigned char century = 0;
-
-	yrs = time->tm_year;
-	mon = time->tm_mon + 1;   /* tm_mon starts at zero */
-	day = time->tm_mday;
-	hrs = time->tm_hour;
-	min = time->tm_min;
-	sec = time->tm_sec;
-
-	if (yrs > 255)	/* They are unsigned */
-		return -EINVAL;
-
-	spin_lock_irqsave(&rtc_lock, flags);
-#ifdef CONFIG_MACH_DECSTATION
-	real_yrs = yrs;
-	leap_yr = ((!((yrs + 1900) % 4) && ((yrs + 1900) % 100)) ||
-			!((yrs + 1900) % 400));
-	yrs = 72;
-
-	/*
-	 * We want to keep the year set to 73 until March
-	 * for non-leap years, so that Feb, 29th is handled
-	 * correctly.
-	 */
-	if (!leap_yr && mon < 3) {
-		real_yrs--;
-		yrs = 73;
-	}
-#endif
-
-#ifdef CONFIG_ACPI
-	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
-	    acpi_gbl_FADT.century) {
-		century = (yrs + 1900) / 100;
-		yrs %= 100;
-	}
-#endif
-
-	/* These limits and adjustments are independent of
-	 * whether the chip is in binary mode or not.
-	 */
-	if (yrs > 169) {
-		spin_unlock_irqrestore(&rtc_lock, flags);
-		return -EINVAL;
-	}
-
-	if (yrs >= 100)
-		yrs -= 100;
-
-	if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY)
-	    || RTC_ALWAYS_BCD) {
-		sec = bin2bcd(sec);
-		min = bin2bcd(min);
-		hrs = bin2bcd(hrs);
-		day = bin2bcd(day);
-		mon = bin2bcd(mon);
-		yrs = bin2bcd(yrs);
-		century = bin2bcd(century);
-	}
-
-	save_control = CMOS_READ(RTC_CONTROL);
-	CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
-	save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
-	CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
-
-#ifdef CONFIG_MACH_DECSTATION
-	CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
-#endif
-	CMOS_WRITE(yrs, RTC_YEAR);
-	CMOS_WRITE(mon, RTC_MONTH);
-	CMOS_WRITE(day, RTC_DAY_OF_MONTH);
-	CMOS_WRITE(hrs, RTC_HOURS);
-	CMOS_WRITE(min, RTC_MINUTES);
-	CMOS_WRITE(sec, RTC_SECONDS);
-#ifdef CONFIG_ACPI
-	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
-	    acpi_gbl_FADT.century)
-		CMOS_WRITE(century, acpi_gbl_FADT.century);
-#endif
-
-	CMOS_WRITE(save_control, RTC_CONTROL);
-	CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
-
-	spin_unlock_irqrestore(&rtc_lock, flags);
-
-	return 0;
-}
-
-#ifndef set_rtc_time
-#define set_rtc_time	__set_rtc_time
-#endif
-
 static inline unsigned int get_rtc_ss(void)
 {
 	struct rtc_time h;
diff --git a/include/linux/mc146818rtc.h b/include/linux/mc146818rtc.h
index 433e0c74d643..e9e346b37846 100644
--- a/include/linux/mc146818rtc.h
+++ b/include/linux/mc146818rtc.h
@@ -14,6 +14,12 @@
 #include <asm/io.h>
 #include <linux/rtc.h>			/* get the user-level API */
 #include <asm/mc146818rtc.h>		/* register access macros */
+#include <linux/bcd.h>
+#include <linux/delay.h>
+
+#ifdef CONFIG_ACPI
+#include <linux/acpi.h>
+#endif
 
 #ifdef __KERNEL__
 #include <linux/spinlock.h>		/* spinlock_t */
@@ -120,4 +126,192 @@ struct cmos_rtc_board_info {
 #define RTC_IO_EXTENT_USED      RTC_IO_EXTENT
 #endif /* ARCH_RTC_LOCATION */
 
+/*
+ * Returns true if a clock update is in progress
+ */
+static inline unsigned char mc146818_is_updating(void)
+{
+	unsigned char uip;
+	unsigned long flags;
+
+	spin_lock_irqsave(&rtc_lock, flags);
+	uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
+	spin_unlock_irqrestore(&rtc_lock, flags);
+	return uip;
+}
+
+static inline unsigned int mc146818_get_time(struct rtc_time *time)
+{
+	unsigned char ctrl;
+	unsigned long flags;
+	unsigned char century = 0;
+
+#ifdef CONFIG_MACH_DECSTATION
+	unsigned int real_year;
+#endif
+
+	/*
+	 * read RTC once any update in progress is done. The update
+	 * can take just over 2ms. We wait 20ms. There is no need to
+	 * to poll-wait (up to 1s - eeccch) for the falling edge of RTC_UIP.
+	 * If you need to know *exactly* when a second has started, enable
+	 * periodic update complete interrupts, (via ioctl) and then 
+	 * immediately read /dev/rtc which will block until you get the IRQ.
+	 * Once the read clears, read the RTC time (again via ioctl). Easy.
+	 */
+	if (mc146818_is_updating())
+		mdelay(20);
+
+	/*
+	 * Only the values that we read from the RTC are set. We leave
+	 * tm_wday, tm_yday and tm_isdst untouched. Even though the
+	 * RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
+	 * by the RTC when initially set to a non-zero value.
+	 */
+	spin_lock_irqsave(&rtc_lock, flags);
+	time->tm_sec = CMOS_READ(RTC_SECONDS);
+	time->tm_min = CMOS_READ(RTC_MINUTES);
+	time->tm_hour = CMOS_READ(RTC_HOURS);
+	time->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH);
+	time->tm_mon = CMOS_READ(RTC_MONTH);
+	time->tm_year = CMOS_READ(RTC_YEAR);
+#ifdef CONFIG_MACH_DECSTATION
+	real_year = CMOS_READ(RTC_DEC_YEAR);
+#endif
+#ifdef CONFIG_ACPI
+	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
+	    acpi_gbl_FADT.century)
+		century = CMOS_READ(acpi_gbl_FADT.century);
+#endif
+	ctrl = CMOS_READ(RTC_CONTROL);
+	spin_unlock_irqrestore(&rtc_lock, flags);
+
+	if (!(ctrl & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
+	{
+		time->tm_sec = bcd2bin(time->tm_sec);
+		time->tm_min = bcd2bin(time->tm_min);
+		time->tm_hour = bcd2bin(time->tm_hour);
+		time->tm_mday = bcd2bin(time->tm_mday);
+		time->tm_mon = bcd2bin(time->tm_mon);
+		time->tm_year = bcd2bin(time->tm_year);
+		century = bcd2bin(century);
+	}
+
+#ifdef CONFIG_MACH_DECSTATION
+	time->tm_year += real_year - 72;
+#endif
+
+	if (century)
+		time->tm_year += (century - 19) * 100;
+
+	/*
+	 * Account for differences between how the RTC uses the values
+	 * and how they are defined in a struct rtc_time;
+	 */
+	if (time->tm_year <= 69)
+		time->tm_year += 100;
+
+	time->tm_mon--;
+
+	return RTC_24H;
+}
+
+/* Set the current date and time in the real time clock. */
+static inline int mc146818_set_time(struct rtc_time *time)
+{
+	unsigned long flags;
+	unsigned char mon, day, hrs, min, sec;
+	unsigned char save_control, save_freq_select;
+	unsigned int yrs;
+#ifdef CONFIG_MACH_DECSTATION
+	unsigned int real_yrs, leap_yr;
+#endif
+	unsigned char century = 0;
+
+	yrs = time->tm_year;
+	mon = time->tm_mon + 1;   /* tm_mon starts at zero */
+	day = time->tm_mday;
+	hrs = time->tm_hour;
+	min = time->tm_min;
+	sec = time->tm_sec;
+
+	if (yrs > 255)	/* They are unsigned */
+		return -EINVAL;
+
+	spin_lock_irqsave(&rtc_lock, flags);
+#ifdef CONFIG_MACH_DECSTATION
+	real_yrs = yrs;
+	leap_yr = ((!((yrs + 1900) % 4) && ((yrs + 1900) % 100)) ||
+			!((yrs + 1900) % 400));
+	yrs = 72;
+
+	/*
+	 * We want to keep the year set to 73 until March
+	 * for non-leap years, so that Feb, 29th is handled
+	 * correctly.
+	 */
+	if (!leap_yr && mon < 3) {
+		real_yrs--;
+		yrs = 73;
+	}
+#endif
+
+#ifdef CONFIG_ACPI
+	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
+	    acpi_gbl_FADT.century) {
+		century = (yrs + 1900) / 100;
+		yrs %= 100;
+	}
+#endif
+
+	/* These limits and adjustments are independent of
+	 * whether the chip is in binary mode or not.
+	 */
+	if (yrs > 169) {
+		spin_unlock_irqrestore(&rtc_lock, flags);
+		return -EINVAL;
+	}
+
+	if (yrs >= 100)
+		yrs -= 100;
+
+	if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY)
+	    || RTC_ALWAYS_BCD) {
+		sec = bin2bcd(sec);
+		min = bin2bcd(min);
+		hrs = bin2bcd(hrs);
+		day = bin2bcd(day);
+		mon = bin2bcd(mon);
+		yrs = bin2bcd(yrs);
+		century = bin2bcd(century);
+	}
+
+	save_control = CMOS_READ(RTC_CONTROL);
+	CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
+	save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
+	CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
+
+#ifdef CONFIG_MACH_DECSTATION
+	CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
+#endif
+	CMOS_WRITE(yrs, RTC_YEAR);
+	CMOS_WRITE(mon, RTC_MONTH);
+	CMOS_WRITE(day, RTC_DAY_OF_MONTH);
+	CMOS_WRITE(hrs, RTC_HOURS);
+	CMOS_WRITE(min, RTC_MINUTES);
+	CMOS_WRITE(sec, RTC_SECONDS);
+#ifdef CONFIG_ACPI
+	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
+	    acpi_gbl_FADT.century)
+		CMOS_WRITE(century, acpi_gbl_FADT.century);
+#endif
+
+	CMOS_WRITE(save_control, RTC_CONTROL);
+	CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
+
+	spin_unlock_irqrestore(&rtc_lock, flags);
+
+	return 0;
+}
+
 #endif /* _MC146818RTC_H */
-- 
2.7.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PATCH 4/8] char/rtc: move mc146818rtc code out of asm-generic/rtc.h

[Arnd Bergmann]

Drivers should not really include stuff from asm-generic directly,
and the PC-style cmos rtc driver does this in order to reuse the
mc146818 implementation of get_rtc_time/set_rtc_time rather than
the architecture specific one for the architecture it gets built for.

To make it more obvious what is going on, this moves and renames the
two functions into include/linux/mc146818rtc.h, which holds the
other mc146818 specific code. Ideally it would be in a .c file,
but that would require extra infrastructure as the functions are
called by multiple drivers with conflicting dependencies.

With this change, the asm-generic/rtc.h header also becomes much
more generic, so it can be reused more easily across any architecture
that still relies on the genrtc driver.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/rtc/rtc-cmos.c      |  12 +--
 include/asm-generic/rtc.h   | 206 ++------------------------------------------
 include/linux/mc146818rtc.h | 194 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 205 insertions(+), 207 deletions(-)

diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 84fb541038be..c7993f18edfa 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -43,7 +43,7 @@
 #include <linux/of_platform.h>
 
 /* this is for "generic access to PC-style RTC" using CMOS_READ/CMOS_WRITE */
-#include <asm-generic/rtc.h>
+#include <linux/mc146818rtc.h>
 
 struct cmos_rtc {
 	struct rtc_device	*rtc;
@@ -190,10 +190,10 @@ static inline void cmos_write_bank2(unsigned char val, unsigned char addr)
 static int cmos_read_time(struct device *dev, struct rtc_time *t)
 {
 	/* REVISIT:  if the clock has a "century" register, use
-	 * that instead of the heuristic in get_rtc_time().
+	 * that instead of the heuristic in mc146818_get_time().
 	 * That'll make Y3K compatility (year > 2070) easy!
 	 */
-	get_rtc_time(t);
+	mc146818_get_time(t);
 	return 0;
 }
 
@@ -205,7 +205,7 @@ static int cmos_set_time(struct device *dev, struct rtc_time *t)
 	 * takes effect exactly 500ms after we write the register.
 	 * (Also queueing and other delays before we get this far.)
 	 */
-	return set_rtc_time(t);
+	return mc146818_set_time(t);
 }
 
 static int cmos_read_alarm(struct device *dev, struct rtc_wkalrm *t)
@@ -1142,14 +1142,14 @@ static __init void cmos_of_init(struct platform_device *pdev)
 	if (val)
 		CMOS_WRITE(be32_to_cpup(val), RTC_FREQ_SELECT);
 
-	get_rtc_time(&time);
+	cmos_read_time(&pdev->dev, &time);
 	ret = rtc_valid_tm(&time);
 	if (ret) {
 		struct rtc_time def_time = {
 			.tm_year = 1,
 			.tm_mday = 1,
 		};
-		set_rtc_time(&def_time);
+		cmos_set_time(&pdev->dev, &def_time);
 	}
 }
 #else
diff --git a/include/asm-generic/rtc.h b/include/asm-generic/rtc.h
index 4e3b6558331e..4fcff22cd707 100644
--- a/include/asm-generic/rtc.h
+++ b/include/asm-generic/rtc.h
@@ -12,12 +12,12 @@
 #ifndef __ASM_RTC_H__
 #define __ASM_RTC_H__
 
-#include <linux/mc146818rtc.h>
 #include <linux/rtc.h>
-#include <linux/bcd.h>
-#include <linux/delay.h>
-#ifdef CONFIG_ACPI
-#include <linux/acpi.h>
+
+#ifndef get_rtc_time
+#include <linux/mc146818rtc.h>
+#define get_rtc_time mc146818_get_time
+#define set_rtc_time mc146818_set_time
 #endif
 
 #define RTC_PIE 0x40		/* periodic interrupt enable */
@@ -31,202 +31,6 @@
 #define RTC_24H 0x02		/* 24 hour mode - else hours bit 7 means pm */
 #define RTC_DST_EN 0x01	        /* auto switch DST - works f. USA only */
 
-/*
- * Returns true if a clock update is in progress
- */
-static inline unsigned char rtc_is_updating(void)
-{
-	unsigned char uip;
-	unsigned long flags;
-
-	spin_lock_irqsave(&rtc_lock, flags);
-	uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
-	spin_unlock_irqrestore(&rtc_lock, flags);
-	return uip;
-}
-
-static inline unsigned int __get_rtc_time(struct rtc_time *time)
-{
-	unsigned char ctrl;
-	unsigned long flags;
-	unsigned char century = 0;
-
-#ifdef CONFIG_MACH_DECSTATION
-	unsigned int real_year;
-#endif
-
-	/*
-	 * read RTC once any update in progress is done. The update
-	 * can take just over 2ms. We wait 20ms. There is no need to
-	 * to poll-wait (up to 1s - eeccch) for the falling edge of RTC_UIP.
-	 * If you need to know *exactly* when a second has started, enable
-	 * periodic update complete interrupts, (via ioctl) and then 
-	 * immediately read /dev/rtc which will block until you get the IRQ.
-	 * Once the read clears, read the RTC time (again via ioctl). Easy.
-	 */
-	if (rtc_is_updating())
-		mdelay(20);
-
-	/*
-	 * Only the values that we read from the RTC are set. We leave
-	 * tm_wday, tm_yday and tm_isdst untouched. Even though the
-	 * RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
-	 * by the RTC when initially set to a non-zero value.
-	 */
-	spin_lock_irqsave(&rtc_lock, flags);
-	time->tm_sec = CMOS_READ(RTC_SECONDS);
-	time->tm_min = CMOS_READ(RTC_MINUTES);
-	time->tm_hour = CMOS_READ(RTC_HOURS);
-	time->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH);
-	time->tm_mon = CMOS_READ(RTC_MONTH);
-	time->tm_year = CMOS_READ(RTC_YEAR);
-#ifdef CONFIG_MACH_DECSTATION
-	real_year = CMOS_READ(RTC_DEC_YEAR);
-#endif
-#ifdef CONFIG_ACPI
-	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
-	    acpi_gbl_FADT.century)
-		century = CMOS_READ(acpi_gbl_FADT.century);
-#endif
-	ctrl = CMOS_READ(RTC_CONTROL);
-	spin_unlock_irqrestore(&rtc_lock, flags);
-
-	if (!(ctrl & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
-	{
-		time->tm_sec = bcd2bin(time->tm_sec);
-		time->tm_min = bcd2bin(time->tm_min);
-		time->tm_hour = bcd2bin(time->tm_hour);
-		time->tm_mday = bcd2bin(time->tm_mday);
-		time->tm_mon = bcd2bin(time->tm_mon);
-		time->tm_year = bcd2bin(time->tm_year);
-		century = bcd2bin(century);
-	}
-
-#ifdef CONFIG_MACH_DECSTATION
-	time->tm_year += real_year - 72;
-#endif
-
-	if (century)
-		time->tm_year += (century - 19) * 100;
-
-	/*
-	 * Account for differences between how the RTC uses the values
-	 * and how they are defined in a struct rtc_time;
-	 */
-	if (time->tm_year <= 69)
-		time->tm_year += 100;
-
-	time->tm_mon--;
-
-	return RTC_24H;
-}
-
-#ifndef get_rtc_time
-#define get_rtc_time	__get_rtc_time
-#endif
-
-/* Set the current date and time in the real time clock. */
-static inline int __set_rtc_time(struct rtc_time *time)
-{
-	unsigned long flags;
-	unsigned char mon, day, hrs, min, sec;
-	unsigned char save_control, save_freq_select;
-	unsigned int yrs;
-#ifdef CONFIG_MACH_DECSTATION
-	unsigned int real_yrs, leap_yr;
-#endif
-	unsigned char century = 0;
-
-	yrs = time->tm_year;
-	mon = time->tm_mon + 1;   /* tm_mon starts at zero */
-	day = time->tm_mday;
-	hrs = time->tm_hour;
-	min = time->tm_min;
-	sec = time->tm_sec;
-
-	if (yrs > 255)	/* They are unsigned */
-		return -EINVAL;
-
-	spin_lock_irqsave(&rtc_lock, flags);
-#ifdef CONFIG_MACH_DECSTATION
-	real_yrs = yrs;
-	leap_yr = ((!((yrs + 1900) % 4) && ((yrs + 1900) % 100)) ||
-			!((yrs + 1900) % 400));
-	yrs = 72;
-
-	/*
-	 * We want to keep the year set to 73 until March
-	 * for non-leap years, so that Feb, 29th is handled
-	 * correctly.
-	 */
-	if (!leap_yr && mon < 3) {
-		real_yrs--;
-		yrs = 73;
-	}
-#endif
-
-#ifdef CONFIG_ACPI
-	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
-	    acpi_gbl_FADT.century) {
-		century = (yrs + 1900) / 100;
-		yrs %= 100;
-	}
-#endif
-
-	/* These limits and adjustments are independent of
-	 * whether the chip is in binary mode or not.
-	 */
-	if (yrs > 169) {
-		spin_unlock_irqrestore(&rtc_lock, flags);
-		return -EINVAL;
-	}
-
-	if (yrs >= 100)
-		yrs -= 100;
-
-	if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY)
-	    || RTC_ALWAYS_BCD) {
-		sec = bin2bcd(sec);
-		min = bin2bcd(min);
-		hrs = bin2bcd(hrs);
-		day = bin2bcd(day);
-		mon = bin2bcd(mon);
-		yrs = bin2bcd(yrs);
-		century = bin2bcd(century);
-	}
-
-	save_control = CMOS_READ(RTC_CONTROL);
-	CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
-	save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
-	CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
-
-#ifdef CONFIG_MACH_DECSTATION
-	CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
-#endif
-	CMOS_WRITE(yrs, RTC_YEAR);
-	CMOS_WRITE(mon, RTC_MONTH);
-	CMOS_WRITE(day, RTC_DAY_OF_MONTH);
-	CMOS_WRITE(hrs, RTC_HOURS);
-	CMOS_WRITE(min, RTC_MINUTES);
-	CMOS_WRITE(sec, RTC_SECONDS);
-#ifdef CONFIG_ACPI
-	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
-	    acpi_gbl_FADT.century)
-		CMOS_WRITE(century, acpi_gbl_FADT.century);
-#endif
-
-	CMOS_WRITE(save_control, RTC_CONTROL);
-	CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
-
-	spin_unlock_irqrestore(&rtc_lock, flags);
-
-	return 0;
-}
-
-#ifndef set_rtc_time
-#define set_rtc_time	__set_rtc_time
-#endif
-
 static inline unsigned int get_rtc_ss(void)
 {
 	struct rtc_time h;
diff --git a/include/linux/mc146818rtc.h b/include/linux/mc146818rtc.h
index 433e0c74d643..e9e346b37846 100644
--- a/include/linux/mc146818rtc.h
+++ b/include/linux/mc146818rtc.h
@@ -14,6 +14,12 @@
 #include <asm/io.h>
 #include <linux/rtc.h>			/* get the user-level API */
 #include <asm/mc146818rtc.h>		/* register access macros */
+#include <linux/bcd.h>
+#include <linux/delay.h>
+
+#ifdef CONFIG_ACPI
+#include <linux/acpi.h>
+#endif
 
 #ifdef __KERNEL__
 #include <linux/spinlock.h>		/* spinlock_t */
@@ -120,4 +126,192 @@ struct cmos_rtc_board_info {
 #define RTC_IO_EXTENT_USED      RTC_IO_EXTENT
 #endif /* ARCH_RTC_LOCATION */
 
+/*
+ * Returns true if a clock update is in progress
+ */
+static inline unsigned char mc146818_is_updating(void)
+{
+	unsigned char uip;
+	unsigned long flags;
+
+	spin_lock_irqsave(&rtc_lock, flags);
+	uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
+	spin_unlock_irqrestore(&rtc_lock, flags);
+	return uip;
+}
+
+static inline unsigned int mc146818_get_time(struct rtc_time *time)
+{
+	unsigned char ctrl;
+	unsigned long flags;
+	unsigned char century = 0;
+
+#ifdef CONFIG_MACH_DECSTATION
+	unsigned int real_year;
+#endif
+
+	/*
+	 * read RTC once any update in progress is done. The update
+	 * can take just over 2ms. We wait 20ms. There is no need to
+	 * to poll-wait (up to 1s - eeccch) for the falling edge of RTC_UIP.
+	 * If you need to know *exactly* when a second has started, enable
+	 * periodic update complete interrupts, (via ioctl) and then 
+	 * immediately read /dev/rtc which will block until you get the IRQ.
+	 * Once the read clears, read the RTC time (again via ioctl). Easy.
+	 */
+	if (mc146818_is_updating())
+		mdelay(20);
+
+	/*
+	 * Only the values that we read from the RTC are set. We leave
+	 * tm_wday, tm_yday and tm_isdst untouched. Even though the
+	 * RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
+	 * by the RTC when initially set to a non-zero value.
+	 */
+	spin_lock_irqsave(&rtc_lock, flags);
+	time->tm_sec = CMOS_READ(RTC_SECONDS);
+	time->tm_min = CMOS_READ(RTC_MINUTES);
+	time->tm_hour = CMOS_READ(RTC_HOURS);
+	time->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH);
+	time->tm_mon = CMOS_READ(RTC_MONTH);
+	time->tm_year = CMOS_READ(RTC_YEAR);
+#ifdef CONFIG_MACH_DECSTATION
+	real_year = CMOS_READ(RTC_DEC_YEAR);
+#endif
+#ifdef CONFIG_ACPI
+	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
+	    acpi_gbl_FADT.century)
+		century = CMOS_READ(acpi_gbl_FADT.century);
+#endif
+	ctrl = CMOS_READ(RTC_CONTROL);
+	spin_unlock_irqrestore(&rtc_lock, flags);
+
+	if (!(ctrl & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
+	{
+		time->tm_sec = bcd2bin(time->tm_sec);
+		time->tm_min = bcd2bin(time->tm_min);
+		time->tm_hour = bcd2bin(time->tm_hour);
+		time->tm_mday = bcd2bin(time->tm_mday);
+		time->tm_mon = bcd2bin(time->tm_mon);
+		time->tm_year = bcd2bin(time->tm_year);
+		century = bcd2bin(century);
+	}
+
+#ifdef CONFIG_MACH_DECSTATION
+	time->tm_year += real_year - 72;
+#endif
+
+	if (century)
+		time->tm_year += (century - 19) * 100;
+
+	/*
+	 * Account for differences between how the RTC uses the values
+	 * and how they are defined in a struct rtc_time;
+	 */
+	if (time->tm_year <= 69)
+		time->tm_year += 100;
+
+	time->tm_mon--;
+
+	return RTC_24H;
+}
+
+/* Set the current date and time in the real time clock. */
+static inline int mc146818_set_time(struct rtc_time *time)
+{
+	unsigned long flags;
+	unsigned char mon, day, hrs, min, sec;
+	unsigned char save_control, save_freq_select;
+	unsigned int yrs;
+#ifdef CONFIG_MACH_DECSTATION
+	unsigned int real_yrs, leap_yr;
+#endif
+	unsigned char century = 0;
+
+	yrs = time->tm_year;
+	mon = time->tm_mon + 1;   /* tm_mon starts at zero */
+	day = time->tm_mday;
+	hrs = time->tm_hour;
+	min = time->tm_min;
+	sec = time->tm_sec;
+
+	if (yrs > 255)	/* They are unsigned */
+		return -EINVAL;
+
+	spin_lock_irqsave(&rtc_lock, flags);
+#ifdef CONFIG_MACH_DECSTATION
+	real_yrs = yrs;
+	leap_yr = ((!((yrs + 1900) % 4) && ((yrs + 1900) % 100)) ||
+			!((yrs + 1900) % 400));
+	yrs = 72;
+
+	/*
+	 * We want to keep the year set to 73 until March
+	 * for non-leap years, so that Feb, 29th is handled
+	 * correctly.
+	 */
+	if (!leap_yr && mon < 3) {
+		real_yrs--;
+		yrs = 73;
+	}
+#endif
+
+#ifdef CONFIG_ACPI
+	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
+	    acpi_gbl_FADT.century) {
+		century = (yrs + 1900) / 100;
+		yrs %= 100;
+	}
+#endif
+
+	/* These limits and adjustments are independent of
+	 * whether the chip is in binary mode or not.
+	 */
+	if (yrs > 169) {
+		spin_unlock_irqrestore(&rtc_lock, flags);
+		return -EINVAL;
+	}
+
+	if (yrs >= 100)
+		yrs -= 100;
+
+	if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY)
+	    || RTC_ALWAYS_BCD) {
+		sec = bin2bcd(sec);
+		min = bin2bcd(min);
+		hrs = bin2bcd(hrs);
+		day = bin2bcd(day);
+		mon = bin2bcd(mon);
+		yrs = bin2bcd(yrs);
+		century = bin2bcd(century);
+	}
+
+	save_control = CMOS_READ(RTC_CONTROL);
+	CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
+	save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
+	CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
+
+#ifdef CONFIG_MACH_DECSTATION
+	CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
+#endif
+	CMOS_WRITE(yrs, RTC_YEAR);
+	CMOS_WRITE(mon, RTC_MONTH);
+	CMOS_WRITE(day, RTC_DAY_OF_MONTH);
+	CMOS_WRITE(hrs, RTC_HOURS);
+	CMOS_WRITE(min, RTC_MINUTES);
+	CMOS_WRITE(sec, RTC_SECONDS);
+#ifdef CONFIG_ACPI
+	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
+	    acpi_gbl_FADT.century)
+		CMOS_WRITE(century, acpi_gbl_FADT.century);
+#endif
+
+	CMOS_WRITE(save_control, RTC_CONTROL);
+	CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
+
+	spin_unlock_irqrestore(&rtc_lock, flags);
+
+	return 0;
+}
+
 #endif /* _MC146818RTC_H */
-- 
2.7.0

Re: [PATCH 4/8] char/rtc: move mc146818rtc code out of asm-generic/rtc.h

[Alexandre Belloni]

The subject should be:
rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h

Else, you can add:
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>


On 26/04/2016 at 23:44:08 +0200, Arnd Bergmann wrote :
> Drivers should not really include stuff from asm-generic directly,
> and the PC-style cmos rtc driver does this in order to reuse the
> mc146818 implementation of get_rtc_time/set_rtc_time rather than
> the architecture specific one for the architecture it gets built for.
> 
> To make it more obvious what is going on, this moves and renames the
> two functions into include/linux/mc146818rtc.h, which holds the
> other mc146818 specific code. Ideally it would be in a .c file,
> but that would require extra infrastructure as the functions are
> called by multiple drivers with conflicting dependencies.
> 
> With this change, the asm-generic/rtc.h header also becomes much
> more generic, so it can be reused more easily across any architecture
> that still relies on the genrtc driver.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/rtc/rtc-cmos.c      |  12 +--
>  include/asm-generic/rtc.h   | 206 ++------------------------------------------
>  include/linux/mc146818rtc.h | 194 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 205 insertions(+), 207 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index 84fb541038be..c7993f18edfa 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -43,7 +43,7 @@
>  #include <linux/of_platform.h>
>  
>  /* this is for "generic access to PC-style RTC" using CMOS_READ/CMOS_WRITE */
> -#include <asm-generic/rtc.h>
> +#include <linux/mc146818rtc.h>
>  
>  struct cmos_rtc {
>  	struct rtc_device	*rtc;
> @@ -190,10 +190,10 @@ static inline void cmos_write_bank2(unsigned char val, unsigned char addr)
>  static int cmos_read_time(struct device *dev, struct rtc_time *t)
>  {
>  	/* REVISIT:  if the clock has a "century" register, use
> -	 * that instead of the heuristic in get_rtc_time().
> +	 * that instead of the heuristic in mc146818_get_time().
>  	 * That'll make Y3K compatility (year > 2070) easy!
>  	 */
> -	get_rtc_time(t);
> +	mc146818_get_time(t);
>  	return 0;
>  }
>  
> @@ -205,7 +205,7 @@ static int cmos_set_time(struct device *dev, struct rtc_time *t)
>  	 * takes effect exactly 500ms after we write the register.
>  	 * (Also queueing and other delays before we get this far.)
>  	 */
> -	return set_rtc_time(t);
> +	return mc146818_set_time(t);
>  }
>  
>  static int cmos_read_alarm(struct device *dev, struct rtc_wkalrm *t)
> @@ -1142,14 +1142,14 @@ static __init void cmos_of_init(struct platform_device *pdev)
>  	if (val)
>  		CMOS_WRITE(be32_to_cpup(val), RTC_FREQ_SELECT);
>  
> -	get_rtc_time(&time);
> +	cmos_read_time(&pdev->dev, &time);
>  	ret = rtc_valid_tm(&time);
>  	if (ret) {
>  		struct rtc_time def_time = {
>  			.tm_year = 1,
>  			.tm_mday = 1,
>  		};
> -		set_rtc_time(&def_time);
> +		cmos_set_time(&pdev->dev, &def_time);
>  	}
>  }
>  #else
> diff --git a/include/asm-generic/rtc.h b/include/asm-generic/rtc.h
> index 4e3b6558331e..4fcff22cd707 100644
> --- a/include/asm-generic/rtc.h
> +++ b/include/asm-generic/rtc.h
> @@ -12,12 +12,12 @@
>  #ifndef __ASM_RTC_H__
>  #define __ASM_RTC_H__
>  
> -#include <linux/mc146818rtc.h>
>  #include <linux/rtc.h>
> -#include <linux/bcd.h>
> -#include <linux/delay.h>
> -#ifdef CONFIG_ACPI
> -#include <linux/acpi.h>
> +
> +#ifndef get_rtc_time
> +#include <linux/mc146818rtc.h>
> +#define get_rtc_time mc146818_get_time
> +#define set_rtc_time mc146818_set_time
>  #endif
>  
>  #define RTC_PIE 0x40		/* periodic interrupt enable */
> @@ -31,202 +31,6 @@
>  #define RTC_24H 0x02		/* 24 hour mode - else hours bit 7 means pm */
>  #define RTC_DST_EN 0x01	        /* auto switch DST - works f. USA only */
>  
> -/*
> - * Returns true if a clock update is in progress
> - */
> -static inline unsigned char rtc_is_updating(void)
> -{
> -	unsigned char uip;
> -	unsigned long flags;
> -
> -	spin_lock_irqsave(&rtc_lock, flags);
> -	uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
> -	spin_unlock_irqrestore(&rtc_lock, flags);
> -	return uip;
> -}
> -
> -static inline unsigned int __get_rtc_time(struct rtc_time *time)
> -{
> -	unsigned char ctrl;
> -	unsigned long flags;
> -	unsigned char century = 0;
> -
> -#ifdef CONFIG_MACH_DECSTATION
> -	unsigned int real_year;
> -#endif
> -
> -	/*
> -	 * read RTC once any update in progress is done. The update
> -	 * can take just over 2ms. We wait 20ms. There is no need to
> -	 * to poll-wait (up to 1s - eeccch) for the falling edge of RTC_UIP.
> -	 * If you need to know *exactly* when a second has started, enable
> -	 * periodic update complete interrupts, (via ioctl) and then 
> -	 * immediately read /dev/rtc which will block until you get the IRQ.
> -	 * Once the read clears, read the RTC time (again via ioctl). Easy.
> -	 */
> -	if (rtc_is_updating())
> -		mdelay(20);
> -
> -	/*
> -	 * Only the values that we read from the RTC are set. We leave
> -	 * tm_wday, tm_yday and tm_isdst untouched. Even though the
> -	 * RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
> -	 * by the RTC when initially set to a non-zero value.
> -	 */
> -	spin_lock_irqsave(&rtc_lock, flags);
> -	time->tm_sec = CMOS_READ(RTC_SECONDS);
> -	time->tm_min = CMOS_READ(RTC_MINUTES);
> -	time->tm_hour = CMOS_READ(RTC_HOURS);
> -	time->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH);
> -	time->tm_mon = CMOS_READ(RTC_MONTH);
> -	time->tm_year = CMOS_READ(RTC_YEAR);
> -#ifdef CONFIG_MACH_DECSTATION
> -	real_year = CMOS_READ(RTC_DEC_YEAR);
> -#endif
> -#ifdef CONFIG_ACPI
> -	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> -	    acpi_gbl_FADT.century)
> -		century = CMOS_READ(acpi_gbl_FADT.century);
> -#endif
> -	ctrl = CMOS_READ(RTC_CONTROL);
> -	spin_unlock_irqrestore(&rtc_lock, flags);
> -
> -	if (!(ctrl & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
> -	{
> -		time->tm_sec = bcd2bin(time->tm_sec);
> -		time->tm_min = bcd2bin(time->tm_min);
> -		time->tm_hour = bcd2bin(time->tm_hour);
> -		time->tm_mday = bcd2bin(time->tm_mday);
> -		time->tm_mon = bcd2bin(time->tm_mon);
> -		time->tm_year = bcd2bin(time->tm_year);
> -		century = bcd2bin(century);
> -	}
> -
> -#ifdef CONFIG_MACH_DECSTATION
> -	time->tm_year += real_year - 72;
> -#endif
> -
> -	if (century)
> -		time->tm_year += (century - 19) * 100;
> -
> -	/*
> -	 * Account for differences between how the RTC uses the values
> -	 * and how they are defined in a struct rtc_time;
> -	 */
> -	if (time->tm_year <= 69)
> -		time->tm_year += 100;
> -
> -	time->tm_mon--;
> -
> -	return RTC_24H;
> -}
> -
> -#ifndef get_rtc_time
> -#define get_rtc_time	__get_rtc_time
> -#endif
> -
> -/* Set the current date and time in the real time clock. */
> -static inline int __set_rtc_time(struct rtc_time *time)
> -{
> -	unsigned long flags;
> -	unsigned char mon, day, hrs, min, sec;
> -	unsigned char save_control, save_freq_select;
> -	unsigned int yrs;
> -#ifdef CONFIG_MACH_DECSTATION
> -	unsigned int real_yrs, leap_yr;
> -#endif
> -	unsigned char century = 0;
> -
> -	yrs = time->tm_year;
> -	mon = time->tm_mon + 1;   /* tm_mon starts at zero */
> -	day = time->tm_mday;
> -	hrs = time->tm_hour;
> -	min = time->tm_min;
> -	sec = time->tm_sec;
> -
> -	if (yrs > 255)	/* They are unsigned */
> -		return -EINVAL;
> -
> -	spin_lock_irqsave(&rtc_lock, flags);
> -#ifdef CONFIG_MACH_DECSTATION
> -	real_yrs = yrs;
> -	leap_yr = ((!((yrs + 1900) % 4) && ((yrs + 1900) % 100)) ||
> -			!((yrs + 1900) % 400));
> -	yrs = 72;
> -
> -	/*
> -	 * We want to keep the year set to 73 until March
> -	 * for non-leap years, so that Feb, 29th is handled
> -	 * correctly.
> -	 */
> -	if (!leap_yr && mon < 3) {
> -		real_yrs--;
> -		yrs = 73;
> -	}
> -#endif
> -
> -#ifdef CONFIG_ACPI
> -	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> -	    acpi_gbl_FADT.century) {
> -		century = (yrs + 1900) / 100;
> -		yrs %= 100;
> -	}
> -#endif
> -
> -	/* These limits and adjustments are independent of
> -	 * whether the chip is in binary mode or not.
> -	 */
> -	if (yrs > 169) {
> -		spin_unlock_irqrestore(&rtc_lock, flags);
> -		return -EINVAL;
> -	}
> -
> -	if (yrs >= 100)
> -		yrs -= 100;
> -
> -	if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY)
> -	    || RTC_ALWAYS_BCD) {
> -		sec = bin2bcd(sec);
> -		min = bin2bcd(min);
> -		hrs = bin2bcd(hrs);
> -		day = bin2bcd(day);
> -		mon = bin2bcd(mon);
> -		yrs = bin2bcd(yrs);
> -		century = bin2bcd(century);
> -	}
> -
> -	save_control = CMOS_READ(RTC_CONTROL);
> -	CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
> -	save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
> -	CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
> -
> -#ifdef CONFIG_MACH_DECSTATION
> -	CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
> -#endif
> -	CMOS_WRITE(yrs, RTC_YEAR);
> -	CMOS_WRITE(mon, RTC_MONTH);
> -	CMOS_WRITE(day, RTC_DAY_OF_MONTH);
> -	CMOS_WRITE(hrs, RTC_HOURS);
> -	CMOS_WRITE(min, RTC_MINUTES);
> -	CMOS_WRITE(sec, RTC_SECONDS);
> -#ifdef CONFIG_ACPI
> -	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> -	    acpi_gbl_FADT.century)
> -		CMOS_WRITE(century, acpi_gbl_FADT.century);
> -#endif
> -
> -	CMOS_WRITE(save_control, RTC_CONTROL);
> -	CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
> -
> -	spin_unlock_irqrestore(&rtc_lock, flags);
> -
> -	return 0;
> -}
> -
> -#ifndef set_rtc_time
> -#define set_rtc_time	__set_rtc_time
> -#endif
> -
>  static inline unsigned int get_rtc_ss(void)
>  {
>  	struct rtc_time h;
> diff --git a/include/linux/mc146818rtc.h b/include/linux/mc146818rtc.h
> index 433e0c74d643..e9e346b37846 100644
> --- a/include/linux/mc146818rtc.h
> +++ b/include/linux/mc146818rtc.h
> @@ -14,6 +14,12 @@
>  #include <asm/io.h>
>  #include <linux/rtc.h>			/* get the user-level API */
>  #include <asm/mc146818rtc.h>		/* register access macros */
> +#include <linux/bcd.h>
> +#include <linux/delay.h>
> +
> +#ifdef CONFIG_ACPI
> +#include <linux/acpi.h>
> +#endif
>  
>  #ifdef __KERNEL__
>  #include <linux/spinlock.h>		/* spinlock_t */
> @@ -120,4 +126,192 @@ struct cmos_rtc_board_info {
>  #define RTC_IO_EXTENT_USED      RTC_IO_EXTENT
>  #endif /* ARCH_RTC_LOCATION */
>  
> +/*
> + * Returns true if a clock update is in progress
> + */
> +static inline unsigned char mc146818_is_updating(void)
> +{
> +	unsigned char uip;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&rtc_lock, flags);
> +	uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
> +	spin_unlock_irqrestore(&rtc_lock, flags);
> +	return uip;
> +}
> +
> +static inline unsigned int mc146818_get_time(struct rtc_time *time)
> +{
> +	unsigned char ctrl;
> +	unsigned long flags;
> +	unsigned char century = 0;
> +
> +#ifdef CONFIG_MACH_DECSTATION
> +	unsigned int real_year;
> +#endif
> +
> +	/*
> +	 * read RTC once any update in progress is done. The update
> +	 * can take just over 2ms. We wait 20ms. There is no need to
> +	 * to poll-wait (up to 1s - eeccch) for the falling edge of RTC_UIP.
> +	 * If you need to know *exactly* when a second has started, enable
> +	 * periodic update complete interrupts, (via ioctl) and then 
> +	 * immediately read /dev/rtc which will block until you get the IRQ.
> +	 * Once the read clears, read the RTC time (again via ioctl). Easy.
> +	 */
> +	if (mc146818_is_updating())
> +		mdelay(20);
> +
> +	/*
> +	 * Only the values that we read from the RTC are set. We leave
> +	 * tm_wday, tm_yday and tm_isdst untouched. Even though the
> +	 * RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
> +	 * by the RTC when initially set to a non-zero value.
> +	 */
> +	spin_lock_irqsave(&rtc_lock, flags);
> +	time->tm_sec = CMOS_READ(RTC_SECONDS);
> +	time->tm_min = CMOS_READ(RTC_MINUTES);
> +	time->tm_hour = CMOS_READ(RTC_HOURS);
> +	time->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH);
> +	time->tm_mon = CMOS_READ(RTC_MONTH);
> +	time->tm_year = CMOS_READ(RTC_YEAR);
> +#ifdef CONFIG_MACH_DECSTATION
> +	real_year = CMOS_READ(RTC_DEC_YEAR);
> +#endif
> +#ifdef CONFIG_ACPI
> +	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> +	    acpi_gbl_FADT.century)
> +		century = CMOS_READ(acpi_gbl_FADT.century);
> +#endif
> +	ctrl = CMOS_READ(RTC_CONTROL);
> +	spin_unlock_irqrestore(&rtc_lock, flags);
> +
> +	if (!(ctrl & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
> +	{
> +		time->tm_sec = bcd2bin(time->tm_sec);
> +		time->tm_min = bcd2bin(time->tm_min);
> +		time->tm_hour = bcd2bin(time->tm_hour);
> +		time->tm_mday = bcd2bin(time->tm_mday);
> +		time->tm_mon = bcd2bin(time->tm_mon);
> +		time->tm_year = bcd2bin(time->tm_year);
> +		century = bcd2bin(century);
> +	}
> +
> +#ifdef CONFIG_MACH_DECSTATION
> +	time->tm_year += real_year - 72;
> +#endif
> +
> +	if (century)
> +		time->tm_year += (century - 19) * 100;
> +
> +	/*
> +	 * Account for differences between how the RTC uses the values
> +	 * and how they are defined in a struct rtc_time;
> +	 */
> +	if (time->tm_year <= 69)
> +		time->tm_year += 100;
> +
> +	time->tm_mon--;
> +
> +	return RTC_24H;
> +}
> +
> +/* Set the current date and time in the real time clock. */
> +static inline int mc146818_set_time(struct rtc_time *time)
> +{
> +	unsigned long flags;
> +	unsigned char mon, day, hrs, min, sec;
> +	unsigned char save_control, save_freq_select;
> +	unsigned int yrs;
> +#ifdef CONFIG_MACH_DECSTATION
> +	unsigned int real_yrs, leap_yr;
> +#endif
> +	unsigned char century = 0;
> +
> +	yrs = time->tm_year;
> +	mon = time->tm_mon + 1;   /* tm_mon starts at zero */
> +	day = time->tm_mday;
> +	hrs = time->tm_hour;
> +	min = time->tm_min;
> +	sec = time->tm_sec;
> +
> +	if (yrs > 255)	/* They are unsigned */
> +		return -EINVAL;
> +
> +	spin_lock_irqsave(&rtc_lock, flags);
> +#ifdef CONFIG_MACH_DECSTATION
> +	real_yrs = yrs;
> +	leap_yr = ((!((yrs + 1900) % 4) && ((yrs + 1900) % 100)) ||
> +			!((yrs + 1900) % 400));
> +	yrs = 72;
> +
> +	/*
> +	 * We want to keep the year set to 73 until March
> +	 * for non-leap years, so that Feb, 29th is handled
> +	 * correctly.
> +	 */
> +	if (!leap_yr && mon < 3) {
> +		real_yrs--;
> +		yrs = 73;
> +	}
> +#endif
> +
> +#ifdef CONFIG_ACPI
> +	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> +	    acpi_gbl_FADT.century) {
> +		century = (yrs + 1900) / 100;
> +		yrs %= 100;
> +	}
> +#endif
> +
> +	/* These limits and adjustments are independent of
> +	 * whether the chip is in binary mode or not.
> +	 */
> +	if (yrs > 169) {
> +		spin_unlock_irqrestore(&rtc_lock, flags);
> +		return -EINVAL;
> +	}
> +
> +	if (yrs >= 100)
> +		yrs -= 100;
> +
> +	if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY)
> +	    || RTC_ALWAYS_BCD) {
> +		sec = bin2bcd(sec);
> +		min = bin2bcd(min);
> +		hrs = bin2bcd(hrs);
> +		day = bin2bcd(day);
> +		mon = bin2bcd(mon);
> +		yrs = bin2bcd(yrs);
> +		century = bin2bcd(century);
> +	}
> +
> +	save_control = CMOS_READ(RTC_CONTROL);
> +	CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
> +	save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
> +	CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
> +
> +#ifdef CONFIG_MACH_DECSTATION
> +	CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
> +#endif
> +	CMOS_WRITE(yrs, RTC_YEAR);
> +	CMOS_WRITE(mon, RTC_MONTH);
> +	CMOS_WRITE(day, RTC_DAY_OF_MONTH);
> +	CMOS_WRITE(hrs, RTC_HOURS);
> +	CMOS_WRITE(min, RTC_MINUTES);
> +	CMOS_WRITE(sec, RTC_SECONDS);
> +#ifdef CONFIG_ACPI
> +	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> +	    acpi_gbl_FADT.century)
> +		CMOS_WRITE(century, acpi_gbl_FADT.century);
> +#endif
> +
> +	CMOS_WRITE(save_control, RTC_CONTROL);
> +	CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
> +
> +	spin_unlock_irqrestore(&rtc_lock, flags);
> +
> +	return 0;
> +}
> +
>  #endif /* _MC146818RTC_H */
> -- 
> 2.7.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[rtc-linux] Re: [PATCH 4/8] char/rtc: move mc146818rtc code out of asm-generic/rtc.h

[Alexandre Belloni]

The subject should be:
rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h

Else, you can add:
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>


On 26/04/2016 at 23:44:08 +0200, Arnd Bergmann wrote :
> Drivers should not really include stuff from asm-generic directly,
> and the PC-style cmos rtc driver does this in order to reuse the
> mc146818 implementation of get_rtc_time/set_rtc_time rather than
> the architecture specific one for the architecture it gets built for.
> 
> To make it more obvious what is going on, this moves and renames the
> two functions into include/linux/mc146818rtc.h, which holds the
> other mc146818 specific code. Ideally it would be in a .c file,
> but that would require extra infrastructure as the functions are
> called by multiple drivers with conflicting dependencies.
> 
> With this change, the asm-generic/rtc.h header also becomes much
> more generic, so it can be reused more easily across any architecture
> that still relies on the genrtc driver.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/rtc/rtc-cmos.c      |  12 +--
>  include/asm-generic/rtc.h   | 206 ++------------------------------------------
>  include/linux/mc146818rtc.h | 194 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 205 insertions(+), 207 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index 84fb541038be..c7993f18edfa 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -43,7 +43,7 @@
>  #include <linux/of_platform.h>
>  
>  /* this is for "generic access to PC-style RTC" using CMOS_READ/CMOS_WRITE */
> -#include <asm-generic/rtc.h>
> +#include <linux/mc146818rtc.h>
>  
>  struct cmos_rtc {
>  	struct rtc_device	*rtc;
> @@ -190,10 +190,10 @@ static inline void cmos_write_bank2(unsigned char val, unsigned char addr)
>  static int cmos_read_time(struct device *dev, struct rtc_time *t)
>  {
>  	/* REVISIT:  if the clock has a "century" register, use
> -	 * that instead of the heuristic in get_rtc_time().
> +	 * that instead of the heuristic in mc146818_get_time().
>  	 * That'll make Y3K compatility (year > 2070) easy!
>  	 */
> -	get_rtc_time(t);
> +	mc146818_get_time(t);
>  	return 0;
>  }
>  
> @@ -205,7 +205,7 @@ static int cmos_set_time(struct device *dev, struct rtc_time *t)
>  	 * takes effect exactly 500ms after we write the register.
>  	 * (Also queueing and other delays before we get this far.)
>  	 */
> -	return set_rtc_time(t);
> +	return mc146818_set_time(t);
>  }
>  
>  static int cmos_read_alarm(struct device *dev, struct rtc_wkalrm *t)
> @@ -1142,14 +1142,14 @@ static __init void cmos_of_init(struct platform_device *pdev)
>  	if (val)
>  		CMOS_WRITE(be32_to_cpup(val), RTC_FREQ_SELECT);
>  
> -	get_rtc_time(&time);
> +	cmos_read_time(&pdev->dev, &time);
>  	ret = rtc_valid_tm(&time);
>  	if (ret) {
>  		struct rtc_time def_time = {
>  			.tm_year = 1,
>  			.tm_mday = 1,
>  		};
> -		set_rtc_time(&def_time);
> +		cmos_set_time(&pdev->dev, &def_time);
>  	}
>  }
>  #else
> diff --git a/include/asm-generic/rtc.h b/include/asm-generic/rtc.h
> index 4e3b6558331e..4fcff22cd707 100644
> --- a/include/asm-generic/rtc.h
> +++ b/include/asm-generic/rtc.h
> @@ -12,12 +12,12 @@
>  #ifndef __ASM_RTC_H__
>  #define __ASM_RTC_H__
>  
> -#include <linux/mc146818rtc.h>
>  #include <linux/rtc.h>
> -#include <linux/bcd.h>
> -#include <linux/delay.h>
> -#ifdef CONFIG_ACPI
> -#include <linux/acpi.h>
> +
> +#ifndef get_rtc_time
> +#include <linux/mc146818rtc.h>
> +#define get_rtc_time mc146818_get_time
> +#define set_rtc_time mc146818_set_time
>  #endif
>  
>  #define RTC_PIE 0x40		/* periodic interrupt enable */
> @@ -31,202 +31,6 @@
>  #define RTC_24H 0x02		/* 24 hour mode - else hours bit 7 means pm */
>  #define RTC_DST_EN 0x01	        /* auto switch DST - works f. USA only */
>  
> -/*
> - * Returns true if a clock update is in progress
> - */
> -static inline unsigned char rtc_is_updating(void)
> -{
> -	unsigned char uip;
> -	unsigned long flags;
> -
> -	spin_lock_irqsave(&rtc_lock, flags);
> -	uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
> -	spin_unlock_irqrestore(&rtc_lock, flags);
> -	return uip;
> -}
> -
> -static inline unsigned int __get_rtc_time(struct rtc_time *time)
> -{
> -	unsigned char ctrl;
> -	unsigned long flags;
> -	unsigned char century = 0;
> -
> -#ifdef CONFIG_MACH_DECSTATION
> -	unsigned int real_year;
> -#endif
> -
> -	/*
> -	 * read RTC once any update in progress is done. The update
> -	 * can take just over 2ms. We wait 20ms. There is no need to
> -	 * to poll-wait (up to 1s - eeccch) for the falling edge of RTC_UIP.
> -	 * If you need to know *exactly* when a second has started, enable
> -	 * periodic update complete interrupts, (via ioctl) and then 
> -	 * immediately read /dev/rtc which will block until you get the IRQ.
> -	 * Once the read clears, read the RTC time (again via ioctl). Easy.
> -	 */
> -	if (rtc_is_updating())
> -		mdelay(20);
> -
> -	/*
> -	 * Only the values that we read from the RTC are set. We leave
> -	 * tm_wday, tm_yday and tm_isdst untouched. Even though the
> -	 * RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
> -	 * by the RTC when initially set to a non-zero value.
> -	 */
> -	spin_lock_irqsave(&rtc_lock, flags);
> -	time->tm_sec = CMOS_READ(RTC_SECONDS);
> -	time->tm_min = CMOS_READ(RTC_MINUTES);
> -	time->tm_hour = CMOS_READ(RTC_HOURS);
> -	time->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH);
> -	time->tm_mon = CMOS_READ(RTC_MONTH);
> -	time->tm_year = CMOS_READ(RTC_YEAR);
> -#ifdef CONFIG_MACH_DECSTATION
> -	real_year = CMOS_READ(RTC_DEC_YEAR);
> -#endif
> -#ifdef CONFIG_ACPI
> -	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> -	    acpi_gbl_FADT.century)
> -		century = CMOS_READ(acpi_gbl_FADT.century);
> -#endif
> -	ctrl = CMOS_READ(RTC_CONTROL);
> -	spin_unlock_irqrestore(&rtc_lock, flags);
> -
> -	if (!(ctrl & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
> -	{
> -		time->tm_sec = bcd2bin(time->tm_sec);
> -		time->tm_min = bcd2bin(time->tm_min);
> -		time->tm_hour = bcd2bin(time->tm_hour);
> -		time->tm_mday = bcd2bin(time->tm_mday);
> -		time->tm_mon = bcd2bin(time->tm_mon);
> -		time->tm_year = bcd2bin(time->tm_year);
> -		century = bcd2bin(century);
> -	}
> -
> -#ifdef CONFIG_MACH_DECSTATION
> -	time->tm_year += real_year - 72;
> -#endif
> -
> -	if (century)
> -		time->tm_year += (century - 19) * 100;
> -
> -	/*
> -	 * Account for differences between how the RTC uses the values
> -	 * and how they are defined in a struct rtc_time;
> -	 */
> -	if (time->tm_year <= 69)
> -		time->tm_year += 100;
> -
> -	time->tm_mon--;
> -
> -	return RTC_24H;
> -}
> -
> -#ifndef get_rtc_time
> -#define get_rtc_time	__get_rtc_time
> -#endif
> -
> -/* Set the current date and time in the real time clock. */
> -static inline int __set_rtc_time(struct rtc_time *time)
> -{
> -	unsigned long flags;
> -	unsigned char mon, day, hrs, min, sec;
> -	unsigned char save_control, save_freq_select;
> -	unsigned int yrs;
> -#ifdef CONFIG_MACH_DECSTATION
> -	unsigned int real_yrs, leap_yr;
> -#endif
> -	unsigned char century = 0;
> -
> -	yrs = time->tm_year;
> -	mon = time->tm_mon + 1;   /* tm_mon starts at zero */
> -	day = time->tm_mday;
> -	hrs = time->tm_hour;
> -	min = time->tm_min;
> -	sec = time->tm_sec;
> -
> -	if (yrs > 255)	/* They are unsigned */
> -		return -EINVAL;
> -
> -	spin_lock_irqsave(&rtc_lock, flags);
> -#ifdef CONFIG_MACH_DECSTATION
> -	real_yrs = yrs;
> -	leap_yr = ((!((yrs + 1900) % 4) && ((yrs + 1900) % 100)) ||
> -			!((yrs + 1900) % 400));
> -	yrs = 72;
> -
> -	/*
> -	 * We want to keep the year set to 73 until March
> -	 * for non-leap years, so that Feb, 29th is handled
> -	 * correctly.
> -	 */
> -	if (!leap_yr && mon < 3) {
> -		real_yrs--;
> -		yrs = 73;
> -	}
> -#endif
> -
> -#ifdef CONFIG_ACPI
> -	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> -	    acpi_gbl_FADT.century) {
> -		century = (yrs + 1900) / 100;
> -		yrs %= 100;
> -	}
> -#endif
> -
> -	/* These limits and adjustments are independent of
> -	 * whether the chip is in binary mode or not.
> -	 */
> -	if (yrs > 169) {
> -		spin_unlock_irqrestore(&rtc_lock, flags);
> -		return -EINVAL;
> -	}
> -
> -	if (yrs >= 100)
> -		yrs -= 100;
> -
> -	if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY)
> -	    || RTC_ALWAYS_BCD) {
> -		sec = bin2bcd(sec);
> -		min = bin2bcd(min);
> -		hrs = bin2bcd(hrs);
> -		day = bin2bcd(day);
> -		mon = bin2bcd(mon);
> -		yrs = bin2bcd(yrs);
> -		century = bin2bcd(century);
> -	}
> -
> -	save_control = CMOS_READ(RTC_CONTROL);
> -	CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
> -	save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
> -	CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
> -
> -#ifdef CONFIG_MACH_DECSTATION
> -	CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
> -#endif
> -	CMOS_WRITE(yrs, RTC_YEAR);
> -	CMOS_WRITE(mon, RTC_MONTH);
> -	CMOS_WRITE(day, RTC_DAY_OF_MONTH);
> -	CMOS_WRITE(hrs, RTC_HOURS);
> -	CMOS_WRITE(min, RTC_MINUTES);
> -	CMOS_WRITE(sec, RTC_SECONDS);
> -#ifdef CONFIG_ACPI
> -	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> -	    acpi_gbl_FADT.century)
> -		CMOS_WRITE(century, acpi_gbl_FADT.century);
> -#endif
> -
> -	CMOS_WRITE(save_control, RTC_CONTROL);
> -	CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
> -
> -	spin_unlock_irqrestore(&rtc_lock, flags);
> -
> -	return 0;
> -}
> -
> -#ifndef set_rtc_time
> -#define set_rtc_time	__set_rtc_time
> -#endif
> -
>  static inline unsigned int get_rtc_ss(void)
>  {
>  	struct rtc_time h;
> diff --git a/include/linux/mc146818rtc.h b/include/linux/mc146818rtc.h
> index 433e0c74d643..e9e346b37846 100644
> --- a/include/linux/mc146818rtc.h
> +++ b/include/linux/mc146818rtc.h
> @@ -14,6 +14,12 @@
>  #include <asm/io.h>
>  #include <linux/rtc.h>			/* get the user-level API */
>  #include <asm/mc146818rtc.h>		/* register access macros */
> +#include <linux/bcd.h>
> +#include <linux/delay.h>
> +
> +#ifdef CONFIG_ACPI
> +#include <linux/acpi.h>
> +#endif
>  
>  #ifdef __KERNEL__
>  #include <linux/spinlock.h>		/* spinlock_t */
> @@ -120,4 +126,192 @@ struct cmos_rtc_board_info {
>  #define RTC_IO_EXTENT_USED      RTC_IO_EXTENT
>  #endif /* ARCH_RTC_LOCATION */
>  
> +/*
> + * Returns true if a clock update is in progress
> + */
> +static inline unsigned char mc146818_is_updating(void)
> +{
> +	unsigned char uip;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&rtc_lock, flags);
> +	uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
> +	spin_unlock_irqrestore(&rtc_lock, flags);
> +	return uip;
> +}
> +
> +static inline unsigned int mc146818_get_time(struct rtc_time *time)
> +{
> +	unsigned char ctrl;
> +	unsigned long flags;
> +	unsigned char century = 0;
> +
> +#ifdef CONFIG_MACH_DECSTATION
> +	unsigned int real_year;
> +#endif
> +
> +	/*
> +	 * read RTC once any update in progress is done. The update
> +	 * can take just over 2ms. We wait 20ms. There is no need to
> +	 * to poll-wait (up to 1s - eeccch) for the falling edge of RTC_UIP.
> +	 * If you need to know *exactly* when a second has started, enable
> +	 * periodic update complete interrupts, (via ioctl) and then 
> +	 * immediately read /dev/rtc which will block until you get the IRQ.
> +	 * Once the read clears, read the RTC time (again via ioctl). Easy.
> +	 */
> +	if (mc146818_is_updating())
> +		mdelay(20);
> +
> +	/*
> +	 * Only the values that we read from the RTC are set. We leave
> +	 * tm_wday, tm_yday and tm_isdst untouched. Even though the
> +	 * RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
> +	 * by the RTC when initially set to a non-zero value.
> +	 */
> +	spin_lock_irqsave(&rtc_lock, flags);
> +	time->tm_sec = CMOS_READ(RTC_SECONDS);
> +	time->tm_min = CMOS_READ(RTC_MINUTES);
> +	time->tm_hour = CMOS_READ(RTC_HOURS);
> +	time->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH);
> +	time->tm_mon = CMOS_READ(RTC_MONTH);
> +	time->tm_year = CMOS_READ(RTC_YEAR);
> +#ifdef CONFIG_MACH_DECSTATION
> +	real_year = CMOS_READ(RTC_DEC_YEAR);
> +#endif
> +#ifdef CONFIG_ACPI
> +	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> +	    acpi_gbl_FADT.century)
> +		century = CMOS_READ(acpi_gbl_FADT.century);
> +#endif
> +	ctrl = CMOS_READ(RTC_CONTROL);
> +	spin_unlock_irqrestore(&rtc_lock, flags);
> +
> +	if (!(ctrl & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
> +	{
> +		time->tm_sec = bcd2bin(time->tm_sec);
> +		time->tm_min = bcd2bin(time->tm_min);
> +		time->tm_hour = bcd2bin(time->tm_hour);
> +		time->tm_mday = bcd2bin(time->tm_mday);
> +		time->tm_mon = bcd2bin(time->tm_mon);
> +		time->tm_year = bcd2bin(time->tm_year);
> +		century = bcd2bin(century);
> +	}
> +
> +#ifdef CONFIG_MACH_DECSTATION
> +	time->tm_year += real_year - 72;
> +#endif
> +
> +	if (century)
> +		time->tm_year += (century - 19) * 100;
> +
> +	/*
> +	 * Account for differences between how the RTC uses the values
> +	 * and how they are defined in a struct rtc_time;
> +	 */
> +	if (time->tm_year <= 69)
> +		time->tm_year += 100;
> +
> +	time->tm_mon--;
> +
> +	return RTC_24H;
> +}
> +
> +/* Set the current date and time in the real time clock. */
> +static inline int mc146818_set_time(struct rtc_time *time)
> +{
> +	unsigned long flags;
> +	unsigned char mon, day, hrs, min, sec;
> +	unsigned char save_control, save_freq_select;
> +	unsigned int yrs;
> +#ifdef CONFIG_MACH_DECSTATION
> +	unsigned int real_yrs, leap_yr;
> +#endif
> +	unsigned char century = 0;
> +
> +	yrs = time->tm_year;
> +	mon = time->tm_mon + 1;   /* tm_mon starts at zero */
> +	day = time->tm_mday;
> +	hrs = time->tm_hour;
> +	min = time->tm_min;
> +	sec = time->tm_sec;
> +
> +	if (yrs > 255)	/* They are unsigned */
> +		return -EINVAL;
> +
> +	spin_lock_irqsave(&rtc_lock, flags);
> +#ifdef CONFIG_MACH_DECSTATION
> +	real_yrs = yrs;
> +	leap_yr = ((!((yrs + 1900) % 4) && ((yrs + 1900) % 100)) ||
> +			!((yrs + 1900) % 400));
> +	yrs = 72;
> +
> +	/*
> +	 * We want to keep the year set to 73 until March
> +	 * for non-leap years, so that Feb, 29th is handled
> +	 * correctly.
> +	 */
> +	if (!leap_yr && mon < 3) {
> +		real_yrs--;
> +		yrs = 73;
> +	}
> +#endif
> +
> +#ifdef CONFIG_ACPI
> +	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> +	    acpi_gbl_FADT.century) {
> +		century = (yrs + 1900) / 100;
> +		yrs %= 100;
> +	}
> +#endif
> +
> +	/* These limits and adjustments are independent of
> +	 * whether the chip is in binary mode or not.
> +	 */
> +	if (yrs > 169) {
> +		spin_unlock_irqrestore(&rtc_lock, flags);
> +		return -EINVAL;
> +	}
> +
> +	if (yrs >= 100)
> +		yrs -= 100;
> +
> +	if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY)
> +	    || RTC_ALWAYS_BCD) {
> +		sec = bin2bcd(sec);
> +		min = bin2bcd(min);
> +		hrs = bin2bcd(hrs);
> +		day = bin2bcd(day);
> +		mon = bin2bcd(mon);
> +		yrs = bin2bcd(yrs);
> +		century = bin2bcd(century);
> +	}
> +
> +	save_control = CMOS_READ(RTC_CONTROL);
> +	CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
> +	save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
> +	CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
> +
> +#ifdef CONFIG_MACH_DECSTATION
> +	CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
> +#endif
> +	CMOS_WRITE(yrs, RTC_YEAR);
> +	CMOS_WRITE(mon, RTC_MONTH);
> +	CMOS_WRITE(day, RTC_DAY_OF_MONTH);
> +	CMOS_WRITE(hrs, RTC_HOURS);
> +	CMOS_WRITE(min, RTC_MINUTES);
> +	CMOS_WRITE(sec, RTC_SECONDS);
> +#ifdef CONFIG_ACPI
> +	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> +	    acpi_gbl_FADT.century)
> +		CMOS_WRITE(century, acpi_gbl_FADT.century);
> +#endif
> +
> +	CMOS_WRITE(save_control, RTC_CONTROL);
> +	CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
> +
> +	spin_unlock_irqrestore(&rtc_lock, flags);
> +
> +	return 0;
> +}
> +
>  #endif /* _MC146818RTC_H */
> -- 
> 2.7.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 4/8] char/rtc: move mc146818rtc code out of asm-generic/rtc.h

[Alexandre Belloni]

The subject should be:
rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h

Else, you can add:
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>


On 26/04/2016 at 23:44:08 +0200, Arnd Bergmann wrote :
> Drivers should not really include stuff from asm-generic directly,
> and the PC-style cmos rtc driver does this in order to reuse the
> mc146818 implementation of get_rtc_time/set_rtc_time rather than
> the architecture specific one for the architecture it gets built for.
> 
> To make it more obvious what is going on, this moves and renames the
> two functions into include/linux/mc146818rtc.h, which holds the
> other mc146818 specific code. Ideally it would be in a .c file,
> but that would require extra infrastructure as the functions are
> called by multiple drivers with conflicting dependencies.
> 
> With this change, the asm-generic/rtc.h header also becomes much
> more generic, so it can be reused more easily across any architecture
> that still relies on the genrtc driver.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/rtc/rtc-cmos.c      |  12 +--
>  include/asm-generic/rtc.h   | 206 ++------------------------------------------
>  include/linux/mc146818rtc.h | 194 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 205 insertions(+), 207 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index 84fb541038be..c7993f18edfa 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -43,7 +43,7 @@
>  #include <linux/of_platform.h>
>  
>  /* this is for "generic access to PC-style RTC" using CMOS_READ/CMOS_WRITE */
> -#include <asm-generic/rtc.h>
> +#include <linux/mc146818rtc.h>
>  
>  struct cmos_rtc {
>  	struct rtc_device	*rtc;
> @@ -190,10 +190,10 @@ static inline void cmos_write_bank2(unsigned char val, unsigned char addr)
>  static int cmos_read_time(struct device *dev, struct rtc_time *t)
>  {
>  	/* REVISIT:  if the clock has a "century" register, use
> -	 * that instead of the heuristic in get_rtc_time().
> +	 * that instead of the heuristic in mc146818_get_time().
>  	 * That'll make Y3K compatility (year > 2070) easy!
>  	 */
> -	get_rtc_time(t);
> +	mc146818_get_time(t);
>  	return 0;
>  }
>  
> @@ -205,7 +205,7 @@ static int cmos_set_time(struct device *dev, struct rtc_time *t)
>  	 * takes effect exactly 500ms after we write the register.
>  	 * (Also queueing and other delays before we get this far.)
>  	 */
> -	return set_rtc_time(t);
> +	return mc146818_set_time(t);
>  }
>  
>  static int cmos_read_alarm(struct device *dev, struct rtc_wkalrm *t)
> @@ -1142,14 +1142,14 @@ static __init void cmos_of_init(struct platform_device *pdev)
>  	if (val)
>  		CMOS_WRITE(be32_to_cpup(val), RTC_FREQ_SELECT);
>  
> -	get_rtc_time(&time);
> +	cmos_read_time(&pdev->dev, &time);
>  	ret = rtc_valid_tm(&time);
>  	if (ret) {
>  		struct rtc_time def_time = {
>  			.tm_year = 1,
>  			.tm_mday = 1,
>  		};
> -		set_rtc_time(&def_time);
> +		cmos_set_time(&pdev->dev, &def_time);
>  	}
>  }
>  #else
> diff --git a/include/asm-generic/rtc.h b/include/asm-generic/rtc.h
> index 4e3b6558331e..4fcff22cd707 100644
> --- a/include/asm-generic/rtc.h
> +++ b/include/asm-generic/rtc.h
> @@ -12,12 +12,12 @@
>  #ifndef __ASM_RTC_H__
>  #define __ASM_RTC_H__
>  
> -#include <linux/mc146818rtc.h>
>  #include <linux/rtc.h>
> -#include <linux/bcd.h>
> -#include <linux/delay.h>
> -#ifdef CONFIG_ACPI
> -#include <linux/acpi.h>
> +
> +#ifndef get_rtc_time
> +#include <linux/mc146818rtc.h>
> +#define get_rtc_time mc146818_get_time
> +#define set_rtc_time mc146818_set_time
>  #endif
>  
>  #define RTC_PIE 0x40		/* periodic interrupt enable */
> @@ -31,202 +31,6 @@
>  #define RTC_24H 0x02		/* 24 hour mode - else hours bit 7 means pm */
>  #define RTC_DST_EN 0x01	        /* auto switch DST - works f. USA only */
>  
> -/*
> - * Returns true if a clock update is in progress
> - */
> -static inline unsigned char rtc_is_updating(void)
> -{
> -	unsigned char uip;
> -	unsigned long flags;
> -
> -	spin_lock_irqsave(&rtc_lock, flags);
> -	uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
> -	spin_unlock_irqrestore(&rtc_lock, flags);
> -	return uip;
> -}
> -
> -static inline unsigned int __get_rtc_time(struct rtc_time *time)
> -{
> -	unsigned char ctrl;
> -	unsigned long flags;
> -	unsigned char century = 0;
> -
> -#ifdef CONFIG_MACH_DECSTATION
> -	unsigned int real_year;
> -#endif
> -
> -	/*
> -	 * read RTC once any update in progress is done. The update
> -	 * can take just over 2ms. We wait 20ms. There is no need to
> -	 * to poll-wait (up to 1s - eeccch) for the falling edge of RTC_UIP.
> -	 * If you need to know *exactly* when a second has started, enable
> -	 * periodic update complete interrupts, (via ioctl) and then 
> -	 * immediately read /dev/rtc which will block until you get the IRQ.
> -	 * Once the read clears, read the RTC time (again via ioctl). Easy.
> -	 */
> -	if (rtc_is_updating())
> -		mdelay(20);
> -
> -	/*
> -	 * Only the values that we read from the RTC are set. We leave
> -	 * tm_wday, tm_yday and tm_isdst untouched. Even though the
> -	 * RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
> -	 * by the RTC when initially set to a non-zero value.
> -	 */
> -	spin_lock_irqsave(&rtc_lock, flags);
> -	time->tm_sec = CMOS_READ(RTC_SECONDS);
> -	time->tm_min = CMOS_READ(RTC_MINUTES);
> -	time->tm_hour = CMOS_READ(RTC_HOURS);
> -	time->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH);
> -	time->tm_mon = CMOS_READ(RTC_MONTH);
> -	time->tm_year = CMOS_READ(RTC_YEAR);
> -#ifdef CONFIG_MACH_DECSTATION
> -	real_year = CMOS_READ(RTC_DEC_YEAR);
> -#endif
> -#ifdef CONFIG_ACPI
> -	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> -	    acpi_gbl_FADT.century)
> -		century = CMOS_READ(acpi_gbl_FADT.century);
> -#endif
> -	ctrl = CMOS_READ(RTC_CONTROL);
> -	spin_unlock_irqrestore(&rtc_lock, flags);
> -
> -	if (!(ctrl & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
> -	{
> -		time->tm_sec = bcd2bin(time->tm_sec);
> -		time->tm_min = bcd2bin(time->tm_min);
> -		time->tm_hour = bcd2bin(time->tm_hour);
> -		time->tm_mday = bcd2bin(time->tm_mday);
> -		time->tm_mon = bcd2bin(time->tm_mon);
> -		time->tm_year = bcd2bin(time->tm_year);
> -		century = bcd2bin(century);
> -	}
> -
> -#ifdef CONFIG_MACH_DECSTATION
> -	time->tm_year += real_year - 72;
> -#endif
> -
> -	if (century)
> -		time->tm_year += (century - 19) * 100;
> -
> -	/*
> -	 * Account for differences between how the RTC uses the values
> -	 * and how they are defined in a struct rtc_time;
> -	 */
> -	if (time->tm_year <= 69)
> -		time->tm_year += 100;
> -
> -	time->tm_mon--;
> -
> -	return RTC_24H;
> -}
> -
> -#ifndef get_rtc_time
> -#define get_rtc_time	__get_rtc_time
> -#endif
> -
> -/* Set the current date and time in the real time clock. */
> -static inline int __set_rtc_time(struct rtc_time *time)
> -{
> -	unsigned long flags;
> -	unsigned char mon, day, hrs, min, sec;
> -	unsigned char save_control, save_freq_select;
> -	unsigned int yrs;
> -#ifdef CONFIG_MACH_DECSTATION
> -	unsigned int real_yrs, leap_yr;
> -#endif
> -	unsigned char century = 0;
> -
> -	yrs = time->tm_year;
> -	mon = time->tm_mon + 1;   /* tm_mon starts at zero */
> -	day = time->tm_mday;
> -	hrs = time->tm_hour;
> -	min = time->tm_min;
> -	sec = time->tm_sec;
> -
> -	if (yrs > 255)	/* They are unsigned */
> -		return -EINVAL;
> -
> -	spin_lock_irqsave(&rtc_lock, flags);
> -#ifdef CONFIG_MACH_DECSTATION
> -	real_yrs = yrs;
> -	leap_yr = ((!((yrs + 1900) % 4) && ((yrs + 1900) % 100)) ||
> -			!((yrs + 1900) % 400));
> -	yrs = 72;
> -
> -	/*
> -	 * We want to keep the year set to 73 until March
> -	 * for non-leap years, so that Feb, 29th is handled
> -	 * correctly.
> -	 */
> -	if (!leap_yr && mon < 3) {
> -		real_yrs--;
> -		yrs = 73;
> -	}
> -#endif
> -
> -#ifdef CONFIG_ACPI
> -	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> -	    acpi_gbl_FADT.century) {
> -		century = (yrs + 1900) / 100;
> -		yrs %= 100;
> -	}
> -#endif
> -
> -	/* These limits and adjustments are independent of
> -	 * whether the chip is in binary mode or not.
> -	 */
> -	if (yrs > 169) {
> -		spin_unlock_irqrestore(&rtc_lock, flags);
> -		return -EINVAL;
> -	}
> -
> -	if (yrs >= 100)
> -		yrs -= 100;
> -
> -	if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY)
> -	    || RTC_ALWAYS_BCD) {
> -		sec = bin2bcd(sec);
> -		min = bin2bcd(min);
> -		hrs = bin2bcd(hrs);
> -		day = bin2bcd(day);
> -		mon = bin2bcd(mon);
> -		yrs = bin2bcd(yrs);
> -		century = bin2bcd(century);
> -	}
> -
> -	save_control = CMOS_READ(RTC_CONTROL);
> -	CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
> -	save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
> -	CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
> -
> -#ifdef CONFIG_MACH_DECSTATION
> -	CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
> -#endif
> -	CMOS_WRITE(yrs, RTC_YEAR);
> -	CMOS_WRITE(mon, RTC_MONTH);
> -	CMOS_WRITE(day, RTC_DAY_OF_MONTH);
> -	CMOS_WRITE(hrs, RTC_HOURS);
> -	CMOS_WRITE(min, RTC_MINUTES);
> -	CMOS_WRITE(sec, RTC_SECONDS);
> -#ifdef CONFIG_ACPI
> -	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> -	    acpi_gbl_FADT.century)
> -		CMOS_WRITE(century, acpi_gbl_FADT.century);
> -#endif
> -
> -	CMOS_WRITE(save_control, RTC_CONTROL);
> -	CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
> -
> -	spin_unlock_irqrestore(&rtc_lock, flags);
> -
> -	return 0;
> -}
> -
> -#ifndef set_rtc_time
> -#define set_rtc_time	__set_rtc_time
> -#endif
> -
>  static inline unsigned int get_rtc_ss(void)
>  {
>  	struct rtc_time h;
> diff --git a/include/linux/mc146818rtc.h b/include/linux/mc146818rtc.h
> index 433e0c74d643..e9e346b37846 100644
> --- a/include/linux/mc146818rtc.h
> +++ b/include/linux/mc146818rtc.h
> @@ -14,6 +14,12 @@
>  #include <asm/io.h>
>  #include <linux/rtc.h>			/* get the user-level API */
>  #include <asm/mc146818rtc.h>		/* register access macros */
> +#include <linux/bcd.h>
> +#include <linux/delay.h>
> +
> +#ifdef CONFIG_ACPI
> +#include <linux/acpi.h>
> +#endif
>  
>  #ifdef __KERNEL__
>  #include <linux/spinlock.h>		/* spinlock_t */
> @@ -120,4 +126,192 @@ struct cmos_rtc_board_info {
>  #define RTC_IO_EXTENT_USED      RTC_IO_EXTENT
>  #endif /* ARCH_RTC_LOCATION */
>  
> +/*
> + * Returns true if a clock update is in progress
> + */
> +static inline unsigned char mc146818_is_updating(void)
> +{
> +	unsigned char uip;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&rtc_lock, flags);
> +	uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
> +	spin_unlock_irqrestore(&rtc_lock, flags);
> +	return uip;
> +}
> +
> +static inline unsigned int mc146818_get_time(struct rtc_time *time)
> +{
> +	unsigned char ctrl;
> +	unsigned long flags;
> +	unsigned char century = 0;
> +
> +#ifdef CONFIG_MACH_DECSTATION
> +	unsigned int real_year;
> +#endif
> +
> +	/*
> +	 * read RTC once any update in progress is done. The update
> +	 * can take just over 2ms. We wait 20ms. There is no need to
> +	 * to poll-wait (up to 1s - eeccch) for the falling edge of RTC_UIP.
> +	 * If you need to know *exactly* when a second has started, enable
> +	 * periodic update complete interrupts, (via ioctl) and then 
> +	 * immediately read /dev/rtc which will block until you get the IRQ.
> +	 * Once the read clears, read the RTC time (again via ioctl). Easy.
> +	 */
> +	if (mc146818_is_updating())
> +		mdelay(20);
> +
> +	/*
> +	 * Only the values that we read from the RTC are set. We leave
> +	 * tm_wday, tm_yday and tm_isdst untouched. Even though the
> +	 * RTC has RTC_DAY_OF_WEEK, we ignore it, as it is only updated
> +	 * by the RTC when initially set to a non-zero value.
> +	 */
> +	spin_lock_irqsave(&rtc_lock, flags);
> +	time->tm_sec = CMOS_READ(RTC_SECONDS);
> +	time->tm_min = CMOS_READ(RTC_MINUTES);
> +	time->tm_hour = CMOS_READ(RTC_HOURS);
> +	time->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH);
> +	time->tm_mon = CMOS_READ(RTC_MONTH);
> +	time->tm_year = CMOS_READ(RTC_YEAR);
> +#ifdef CONFIG_MACH_DECSTATION
> +	real_year = CMOS_READ(RTC_DEC_YEAR);
> +#endif
> +#ifdef CONFIG_ACPI
> +	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> +	    acpi_gbl_FADT.century)
> +		century = CMOS_READ(acpi_gbl_FADT.century);
> +#endif
> +	ctrl = CMOS_READ(RTC_CONTROL);
> +	spin_unlock_irqrestore(&rtc_lock, flags);
> +
> +	if (!(ctrl & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
> +	{
> +		time->tm_sec = bcd2bin(time->tm_sec);
> +		time->tm_min = bcd2bin(time->tm_min);
> +		time->tm_hour = bcd2bin(time->tm_hour);
> +		time->tm_mday = bcd2bin(time->tm_mday);
> +		time->tm_mon = bcd2bin(time->tm_mon);
> +		time->tm_year = bcd2bin(time->tm_year);
> +		century = bcd2bin(century);
> +	}
> +
> +#ifdef CONFIG_MACH_DECSTATION
> +	time->tm_year += real_year - 72;
> +#endif
> +
> +	if (century)
> +		time->tm_year += (century - 19) * 100;
> +
> +	/*
> +	 * Account for differences between how the RTC uses the values
> +	 * and how they are defined in a struct rtc_time;
> +	 */
> +	if (time->tm_year <= 69)
> +		time->tm_year += 100;
> +
> +	time->tm_mon--;
> +
> +	return RTC_24H;
> +}
> +
> +/* Set the current date and time in the real time clock. */
> +static inline int mc146818_set_time(struct rtc_time *time)
> +{
> +	unsigned long flags;
> +	unsigned char mon, day, hrs, min, sec;
> +	unsigned char save_control, save_freq_select;
> +	unsigned int yrs;
> +#ifdef CONFIG_MACH_DECSTATION
> +	unsigned int real_yrs, leap_yr;
> +#endif
> +	unsigned char century = 0;
> +
> +	yrs = time->tm_year;
> +	mon = time->tm_mon + 1;   /* tm_mon starts at zero */
> +	day = time->tm_mday;
> +	hrs = time->tm_hour;
> +	min = time->tm_min;
> +	sec = time->tm_sec;
> +
> +	if (yrs > 255)	/* They are unsigned */
> +		return -EINVAL;
> +
> +	spin_lock_irqsave(&rtc_lock, flags);
> +#ifdef CONFIG_MACH_DECSTATION
> +	real_yrs = yrs;
> +	leap_yr = ((!((yrs + 1900) % 4) && ((yrs + 1900) % 100)) ||
> +			!((yrs + 1900) % 400));
> +	yrs = 72;
> +
> +	/*
> +	 * We want to keep the year set to 73 until March
> +	 * for non-leap years, so that Feb, 29th is handled
> +	 * correctly.
> +	 */
> +	if (!leap_yr && mon < 3) {
> +		real_yrs--;
> +		yrs = 73;
> +	}
> +#endif
> +
> +#ifdef CONFIG_ACPI
> +	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> +	    acpi_gbl_FADT.century) {
> +		century = (yrs + 1900) / 100;
> +		yrs %= 100;
> +	}
> +#endif
> +
> +	/* These limits and adjustments are independent of
> +	 * whether the chip is in binary mode or not.
> +	 */
> +	if (yrs > 169) {
> +		spin_unlock_irqrestore(&rtc_lock, flags);
> +		return -EINVAL;
> +	}
> +
> +	if (yrs >= 100)
> +		yrs -= 100;
> +
> +	if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY)
> +	    || RTC_ALWAYS_BCD) {
> +		sec = bin2bcd(sec);
> +		min = bin2bcd(min);
> +		hrs = bin2bcd(hrs);
> +		day = bin2bcd(day);
> +		mon = bin2bcd(mon);
> +		yrs = bin2bcd(yrs);
> +		century = bin2bcd(century);
> +	}
> +
> +	save_control = CMOS_READ(RTC_CONTROL);
> +	CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
> +	save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
> +	CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
> +
> +#ifdef CONFIG_MACH_DECSTATION
> +	CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
> +#endif
> +	CMOS_WRITE(yrs, RTC_YEAR);
> +	CMOS_WRITE(mon, RTC_MONTH);
> +	CMOS_WRITE(day, RTC_DAY_OF_MONTH);
> +	CMOS_WRITE(hrs, RTC_HOURS);
> +	CMOS_WRITE(min, RTC_MINUTES);
> +	CMOS_WRITE(sec, RTC_SECONDS);
> +#ifdef CONFIG_ACPI
> +	if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
> +	    acpi_gbl_FADT.century)
> +		CMOS_WRITE(century, acpi_gbl_FADT.century);
> +#endif
> +
> +	CMOS_WRITE(save_control, RTC_CONTROL);
> +	CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
> +
> +	spin_unlock_irqrestore(&rtc_lock, flags);
> +
> +	return 0;
> +}
> +
>  #endif /* _MC146818RTC_H */
> -- 
> 2.7.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH 4/8] char/rtc: move mc146818rtc code out of asm-generic/rtc.h

[Arnd Bergmann]

On Wednesday 27 April 2016 11:29:12 Alexandre Belloni wrote:
> The subject should be:
> rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h

Good point, the functions are only used by rtc-cmos, not the old
drivers/char/rtc.c.
 
> Else, you can add:
> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

Thanks.

	Arnd

[rtc-linux] Re: [PATCH 4/8] char/rtc: move mc146818rtc code out of asm-generic/rtc.h

[Arnd Bergmann]

On Wednesday 27 April 2016 11:29:12 Alexandre Belloni wrote:
> The subject should be:
> rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h

Good point, the functions are only used by rtc-cmos, not the old
drivers/char/rtc.c.
 
> Else, you can add:
> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

Thanks.

	Arnd

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 4/8] char/rtc: move mc146818rtc code out of asm-generic/rtc.h

[Arnd Bergmann]

On Wednesday 27 April 2016 11:29:12 Alexandre Belloni wrote:
> The subject should be:
> rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h

Good point, the functions are only used by rtc-cmos, not the old
drivers/char/rtc.c.
 
> Else, you can add:
> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

Thanks.

	Arnd

[PATCH 5/8] char/genrtc: powerpc: use asm-generic/rtc.h

[Arnd Bergmann]

The asm-generic/rtc.h header can now be included by
architectures that provide their own set_rtc_time/get_rtc_time
macros, letting us remove most of the common contents in
the powerpc implementation.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/powerpc/include/asm/rtc.h | 36 +++++-------------------------------
 1 file changed, 5 insertions(+), 31 deletions(-)

diff --git a/arch/powerpc/include/asm/rtc.h b/arch/powerpc/include/asm/rtc.h
index f5802926b6c0..c6659582bd1e 100644
--- a/arch/powerpc/include/asm/rtc.h
+++ b/arch/powerpc/include/asm/rtc.h
@@ -26,23 +26,14 @@
 
 #ifdef __KERNEL__
 
-#include <linux/rtc.h>
+#define get_rtc_time powerpc_get_rtc_time
+#define set_rtc_time powerpc_set_rtc_time
+#include <asm-generic/rtc.h>
 
 #include <asm/machdep.h>
 #include <asm/time.h>
 
-#define RTC_PIE 0x40		/* periodic interrupt enable */
-#define RTC_AIE 0x20		/* alarm interrupt enable */
-#define RTC_UIE 0x10		/* update-finished interrupt enable */
-
-/* some dummy definitions */
-#define RTC_BATT_BAD 0x100	/* battery bad */
-#define RTC_SQWE 0x08		/* enable square-wave output */
-#define RTC_DM_BINARY 0x04	/* all time/date values are BCD if clear */
-#define RTC_24H 0x02		/* 24 hour mode - else hours bit 7 means pm */
-#define RTC_DST_EN 0x01	        /* auto switch DST - works f. USA only */
-
-static inline unsigned int get_rtc_time(struct rtc_time *time)
+static inline unsigned int powerpc_get_rtc_time(struct rtc_time *time)
 {
 	if (ppc_md.get_rtc_time)
 		ppc_md.get_rtc_time(time);
@@ -50,29 +41,12 @@ static inline unsigned int get_rtc_time(struct rtc_time *time)
 }
 
 /* Set the current date and time in the real time clock. */
-static inline int set_rtc_time(struct rtc_time *time)
+static inline int powerpc_set_rtc_time(struct rtc_time *time)
 {
 	if (ppc_md.set_rtc_time)
 		return ppc_md.set_rtc_time(time);
 	return -EINVAL;
 }
 
-static inline unsigned int get_rtc_ss(void)
-{
-	struct rtc_time h;
-
-	get_rtc_time(&h);
-	return h.tm_sec;
-}
-
-static inline int get_rtc_pll(struct rtc_pll_info *pll)
-{
-	return -EINVAL;
-}
-static inline int set_rtc_pll(struct rtc_pll_info *pll)
-{
-	return -EINVAL;
-}
-
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_RTC_H__ */
-- 
2.7.0

[rtc-linux] [PATCH 5/8] char/genrtc: powerpc: use asm-generic/rtc.h

[Arnd Bergmann]

The asm-generic/rtc.h header can now be included by
architectures that provide their own set_rtc_time/get_rtc_time
macros, letting us remove most of the common contents in
the powerpc implementation.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/powerpc/include/asm/rtc.h | 36 +++++-------------------------------
 1 file changed, 5 insertions(+), 31 deletions(-)

diff --git a/arch/powerpc/include/asm/rtc.h b/arch/powerpc/include/asm/rtc.h
index f5802926b6c0..c6659582bd1e 100644
--- a/arch/powerpc/include/asm/rtc.h
+++ b/arch/powerpc/include/asm/rtc.h
@@ -26,23 +26,14 @@
 
 #ifdef __KERNEL__
 
-#include <linux/rtc.h>
+#define get_rtc_time powerpc_get_rtc_time
+#define set_rtc_time powerpc_set_rtc_time
+#include <asm-generic/rtc.h>
 
 #include <asm/machdep.h>
 #include <asm/time.h>
 
-#define RTC_PIE 0x40		/* periodic interrupt enable */
-#define RTC_AIE 0x20		/* alarm interrupt enable */
-#define RTC_UIE 0x10		/* update-finished interrupt enable */
-
-/* some dummy definitions */
-#define RTC_BATT_BAD 0x100	/* battery bad */
-#define RTC_SQWE 0x08		/* enable square-wave output */
-#define RTC_DM_BINARY 0x04	/* all time/date values are BCD if clear */
-#define RTC_24H 0x02		/* 24 hour mode - else hours bit 7 means pm */
-#define RTC_DST_EN 0x01	        /* auto switch DST - works f. USA only */
-
-static inline unsigned int get_rtc_time(struct rtc_time *time)
+static inline unsigned int powerpc_get_rtc_time(struct rtc_time *time)
 {
 	if (ppc_md.get_rtc_time)
 		ppc_md.get_rtc_time(time);
@@ -50,29 +41,12 @@ static inline unsigned int get_rtc_time(struct rtc_time *time)
 }
 
 /* Set the current date and time in the real time clock. */
-static inline int set_rtc_time(struct rtc_time *time)
+static inline int powerpc_set_rtc_time(struct rtc_time *time)
 {
 	if (ppc_md.set_rtc_time)
 		return ppc_md.set_rtc_time(time);
 	return -EINVAL;
 }
 
-static inline unsigned int get_rtc_ss(void)
-{
-	struct rtc_time h;
-
-	get_rtc_time(&h);
-	return h.tm_sec;
-}
-
-static inline int get_rtc_pll(struct rtc_pll_info *pll)
-{
-	return -EINVAL;
-}
-static inline int set_rtc_pll(struct rtc_pll_info *pll)
-{
-	return -EINVAL;
-}
-
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_RTC_H__ */
-- 
2.7.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PATCH 5/8] char/genrtc: powerpc: use asm-generic/rtc.h

[Arnd Bergmann]

The asm-generic/rtc.h header can now be included by
architectures that provide their own set_rtc_time/get_rtc_time
macros, letting us remove most of the common contents in
the powerpc implementation.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/powerpc/include/asm/rtc.h | 36 +++++-------------------------------
 1 file changed, 5 insertions(+), 31 deletions(-)

diff --git a/arch/powerpc/include/asm/rtc.h b/arch/powerpc/include/asm/rtc.h
index f5802926b6c0..c6659582bd1e 100644
--- a/arch/powerpc/include/asm/rtc.h
+++ b/arch/powerpc/include/asm/rtc.h
@@ -26,23 +26,14 @@
 
 #ifdef __KERNEL__
 
-#include <linux/rtc.h>
+#define get_rtc_time powerpc_get_rtc_time
+#define set_rtc_time powerpc_set_rtc_time
+#include <asm-generic/rtc.h>
 
 #include <asm/machdep.h>
 #include <asm/time.h>
 
-#define RTC_PIE 0x40		/* periodic interrupt enable */
-#define RTC_AIE 0x20		/* alarm interrupt enable */
-#define RTC_UIE 0x10		/* update-finished interrupt enable */
-
-/* some dummy definitions */
-#define RTC_BATT_BAD 0x100	/* battery bad */
-#define RTC_SQWE 0x08		/* enable square-wave output */
-#define RTC_DM_BINARY 0x04	/* all time/date values are BCD if clear */
-#define RTC_24H 0x02		/* 24 hour mode - else hours bit 7 means pm */
-#define RTC_DST_EN 0x01	        /* auto switch DST - works f. USA only */
-
-static inline unsigned int get_rtc_time(struct rtc_time *time)
+static inline unsigned int powerpc_get_rtc_time(struct rtc_time *time)
 {
 	if (ppc_md.get_rtc_time)
 		ppc_md.get_rtc_time(time);
@@ -50,29 +41,12 @@ static inline unsigned int get_rtc_time(struct rtc_time *time)
 }
 
 /* Set the current date and time in the real time clock. */
-static inline int set_rtc_time(struct rtc_time *time)
+static inline int powerpc_set_rtc_time(struct rtc_time *time)
 {
 	if (ppc_md.set_rtc_time)
 		return ppc_md.set_rtc_time(time);
 	return -EINVAL;
 }
 
-static inline unsigned int get_rtc_ss(void)
-{
-	struct rtc_time h;
-
-	get_rtc_time(&h);
-	return h.tm_sec;
-}
-
-static inline int get_rtc_pll(struct rtc_pll_info *pll)
-{
-	return -EINVAL;
-}
-static inline int set_rtc_pll(struct rtc_pll_info *pll)
-{
-	return -EINVAL;
-}
-
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_RTC_H__ */
-- 
2.7.0

[PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Arnd Bergmann]

The asm-generic/rtc.h header can now be included by
architectures that provide their own set_rtc_time/get_rtc_time
macros, letting us remove most of the common contents in
the powerpc implementation.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/parisc/include/asm/rtc.h | 38 +++++---------------------------------
 1 file changed, 5 insertions(+), 33 deletions(-)

diff --git a/arch/parisc/include/asm/rtc.h b/arch/parisc/include/asm/rtc.h
index 099d641a42c2..d06cc581ecc2 100644
--- a/arch/parisc/include/asm/rtc.h
+++ b/arch/parisc/include/asm/rtc.h
@@ -12,26 +12,15 @@
 
 #ifdef __KERNEL__
 
-#include <linux/rtc.h>
+#define get_rtc_time parisc_get_rtc_time
+#define set_rtc_time parisc_set_rtc_time
+#include <asm-generic/rtc.h>
 
 #include <asm/pdc.h>
 
 #define SECS_PER_HOUR   (60 * 60)
 #define SECS_PER_DAY    (SECS_PER_HOUR * 24)
 
-
-#define RTC_PIE 0x40		/* periodic interrupt enable */
-#define RTC_AIE 0x20		/* alarm interrupt enable */
-#define RTC_UIE 0x10		/* update-finished interrupt enable */
-
-#define RTC_BATT_BAD 0x100	/* battery bad */
-
-/* some dummy definitions */
-#define RTC_SQWE 0x08		/* enable square-wave output */
-#define RTC_DM_BINARY 0x04	/* all time/date values are BCD if clear */
-#define RTC_24H 0x02		/* 24 hour mode - else hours bit 7 means pm */
-#define RTC_DST_EN 0x01	        /* auto switch DST - works f. USA only */
-
 # define __isleap(year) \
   ((year) % 4 = 0 && ((year) % 100 != 0 || (year) % 400 = 0))
 
@@ -44,7 +33,7 @@ static const unsigned short int __mon_yday[2][13]  	{ 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366 }
 };
 
-static inline unsigned int get_rtc_time(struct rtc_time *wtime)
+static inline unsigned int parisc_get_rtc_time(struct rtc_time *wtime)
 {
 	struct pdc_tod tod_data;
 	long int days, rem, y;
@@ -96,7 +85,7 @@ static inline unsigned int get_rtc_time(struct rtc_time *wtime)
 	return RTC_24H;
 }
 
-static int set_rtc_time(struct rtc_time *wtime)
+static int parisc_set_rtc_time(struct rtc_time *wtime)
 {
 	u_int32_t secs;
 
@@ -110,22 +99,5 @@ static int set_rtc_time(struct rtc_time *wtime)
 
 }
 
-static inline unsigned int get_rtc_ss(void)
-{
-	struct rtc_time h;
-
-	get_rtc_time(&h);
-	return h.tm_sec;
-}
-
-static inline int get_rtc_pll(struct rtc_pll_info *pll)
-{
-	return -EINVAL;
-}
-static inline int set_rtc_pll(struct rtc_pll_info *pll)
-{
-	return -EINVAL;
-}
-
 #endif /* __KERNEL__ */
 #endif /* __ASM_RTC_H__ */
-- 
2.7.0

[rtc-linux] [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Arnd Bergmann]

The asm-generic/rtc.h header can now be included by
architectures that provide their own set_rtc_time/get_rtc_time
macros, letting us remove most of the common contents in
the powerpc implementation.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/parisc/include/asm/rtc.h | 38 +++++---------------------------------
 1 file changed, 5 insertions(+), 33 deletions(-)

diff --git a/arch/parisc/include/asm/rtc.h b/arch/parisc/include/asm/rtc.h
index 099d641a42c2..d06cc581ecc2 100644
--- a/arch/parisc/include/asm/rtc.h
+++ b/arch/parisc/include/asm/rtc.h
@@ -12,26 +12,15 @@
 
 #ifdef __KERNEL__
 
-#include <linux/rtc.h>
+#define get_rtc_time parisc_get_rtc_time
+#define set_rtc_time parisc_set_rtc_time
+#include <asm-generic/rtc.h>
 
 #include <asm/pdc.h>
 
 #define SECS_PER_HOUR   (60 * 60)
 #define SECS_PER_DAY    (SECS_PER_HOUR * 24)
 
-
-#define RTC_PIE 0x40		/* periodic interrupt enable */
-#define RTC_AIE 0x20		/* alarm interrupt enable */
-#define RTC_UIE 0x10		/* update-finished interrupt enable */
-
-#define RTC_BATT_BAD 0x100	/* battery bad */
-
-/* some dummy definitions */
-#define RTC_SQWE 0x08		/* enable square-wave output */
-#define RTC_DM_BINARY 0x04	/* all time/date values are BCD if clear */
-#define RTC_24H 0x02		/* 24 hour mode - else hours bit 7 means pm */
-#define RTC_DST_EN 0x01	        /* auto switch DST - works f. USA only */
-
 # define __isleap(year) \
   ((year) % 4 == 0 && ((year) % 100 != 0 || (year) % 400 == 0))
 
@@ -44,7 +33,7 @@ static const unsigned short int __mon_yday[2][13] =
 	{ 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366 }
 };
 
-static inline unsigned int get_rtc_time(struct rtc_time *wtime)
+static inline unsigned int parisc_get_rtc_time(struct rtc_time *wtime)
 {
 	struct pdc_tod tod_data;
 	long int days, rem, y;
@@ -96,7 +85,7 @@ static inline unsigned int get_rtc_time(struct rtc_time *wtime)
 	return RTC_24H;
 }
 
-static int set_rtc_time(struct rtc_time *wtime)
+static int parisc_set_rtc_time(struct rtc_time *wtime)
 {
 	u_int32_t secs;
 
@@ -110,22 +99,5 @@ static int set_rtc_time(struct rtc_time *wtime)
 
 }
 
-static inline unsigned int get_rtc_ss(void)
-{
-	struct rtc_time h;
-
-	get_rtc_time(&h);
-	return h.tm_sec;
-}
-
-static inline int get_rtc_pll(struct rtc_pll_info *pll)
-{
-	return -EINVAL;
-}
-static inline int set_rtc_pll(struct rtc_pll_info *pll)
-{
-	return -EINVAL;
-}
-
 #endif /* __KERNEL__ */
 #endif /* __ASM_RTC_H__ */
-- 
2.7.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Arnd Bergmann]

The asm-generic/rtc.h header can now be included by
architectures that provide their own set_rtc_time/get_rtc_time
macros, letting us remove most of the common contents in
the powerpc implementation.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/parisc/include/asm/rtc.h | 38 +++++---------------------------------
 1 file changed, 5 insertions(+), 33 deletions(-)

diff --git a/arch/parisc/include/asm/rtc.h b/arch/parisc/include/asm/rtc.h
index 099d641a42c2..d06cc581ecc2 100644
--- a/arch/parisc/include/asm/rtc.h
+++ b/arch/parisc/include/asm/rtc.h
@@ -12,26 +12,15 @@
 
 #ifdef __KERNEL__
 
-#include <linux/rtc.h>
+#define get_rtc_time parisc_get_rtc_time
+#define set_rtc_time parisc_set_rtc_time
+#include <asm-generic/rtc.h>
 
 #include <asm/pdc.h>
 
 #define SECS_PER_HOUR   (60 * 60)
 #define SECS_PER_DAY    (SECS_PER_HOUR * 24)
 
-
-#define RTC_PIE 0x40		/* periodic interrupt enable */
-#define RTC_AIE 0x20		/* alarm interrupt enable */
-#define RTC_UIE 0x10		/* update-finished interrupt enable */
-
-#define RTC_BATT_BAD 0x100	/* battery bad */
-
-/* some dummy definitions */
-#define RTC_SQWE 0x08		/* enable square-wave output */
-#define RTC_DM_BINARY 0x04	/* all time/date values are BCD if clear */
-#define RTC_24H 0x02		/* 24 hour mode - else hours bit 7 means pm */
-#define RTC_DST_EN 0x01	        /* auto switch DST - works f. USA only */
-
 # define __isleap(year) \
   ((year) % 4 == 0 && ((year) % 100 != 0 || (year) % 400 == 0))
 
@@ -44,7 +33,7 @@ static const unsigned short int __mon_yday[2][13] =
 	{ 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366 }
 };
 
-static inline unsigned int get_rtc_time(struct rtc_time *wtime)
+static inline unsigned int parisc_get_rtc_time(struct rtc_time *wtime)
 {
 	struct pdc_tod tod_data;
 	long int days, rem, y;
@@ -96,7 +85,7 @@ static inline unsigned int get_rtc_time(struct rtc_time *wtime)
 	return RTC_24H;
 }
 
-static int set_rtc_time(struct rtc_time *wtime)
+static int parisc_set_rtc_time(struct rtc_time *wtime)
 {
 	u_int32_t secs;
 
@@ -110,22 +99,5 @@ static int set_rtc_time(struct rtc_time *wtime)
 
 }
 
-static inline unsigned int get_rtc_ss(void)
-{
-	struct rtc_time h;
-
-	get_rtc_time(&h);
-	return h.tm_sec;
-}
-
-static inline int get_rtc_pll(struct rtc_pll_info *pll)
-{
-	return -EINVAL;
-}
-static inline int set_rtc_pll(struct rtc_pll_info *pll)
-{
-	return -EINVAL;
-}
-
 #endif /* __KERNEL__ */
 #endif /* __ASM_RTC_H__ */
-- 
2.7.0

Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Rolf Eike Beer]

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

Arnd Bergmann wrote:
> The asm-generic/rtc.h header can now be included by
> architectures that provide their own set_rtc_time/get_rtc_time
> macros, letting us remove most of the common contents in
> the powerpc implementation.

parisc in this case.

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Rolf Eike Beer]

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

Arnd Bergmann wrote:
> The asm-generic/rtc.h header can now be included by
> architectures that provide their own set_rtc_time/get_rtc_time
> macros, letting us remove most of the common contents in
> the powerpc implementation.

parisc in this case.

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Arnd Bergmann]

On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
> Arnd Bergmann wrote:
> > The asm-generic/rtc.h header can now be included by
> > architectures that provide their own set_rtc_time/get_rtc_time
> > macros, letting us remove most of the common contents in
> > the powerpc implementation.
> 
> parisc in this case.
> 

Fixed, thanks!

	Arnd

[rtc-linux] Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Arnd Bergmann]

On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
> Arnd Bergmann wrote:
> > The asm-generic/rtc.h header can now be included by
> > architectures that provide their own set_rtc_time/get_rtc_time
> > macros, letting us remove most of the common contents in
> > the powerpc implementation.
> 
> parisc in this case.
> 

Fixed, thanks!

	Arnd

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Arnd Bergmann]

On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
> Arnd Bergmann wrote:
> > The asm-generic/rtc.h header can now be included by
> > architectures that provide their own set_rtc_time/get_rtc_time
> > macros, letting us remove most of the common contents in
> > the powerpc implementation.
> 
> parisc in this case.
> 

Fixed, thanks!

	Arnd

Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Arnd Bergmann]

On Wednesday 27 April 2016 13:21:16 Arnd Bergmann wrote:
> On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
> > Arnd Bergmann wrote:
> > > The asm-generic/rtc.h header can now be included by
> > > architectures that provide their own set_rtc_time/get_rtc_time
> > > macros, letting us remove most of the common contents in
> > > the powerpc implementation.
> > 
> > parisc in this case.
> > 
> 
> Fixed, thanks!

Actually, after the comment about just removing the gen_rtc driver
in the long run, I checked again and found that PARISC unconditionally
selects RTC_CLASS, so this driver can't even be built here.
We should just remove the header and drop PARISC from the list.

If we also drop m68k, that just leaves powerpc.

	Arnd

[rtc-linux] Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Arnd Bergmann]

On Wednesday 27 April 2016 13:21:16 Arnd Bergmann wrote:
> On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
> > Arnd Bergmann wrote:
> > > The asm-generic/rtc.h header can now be included by
> > > architectures that provide their own set_rtc_time/get_rtc_time
> > > macros, letting us remove most of the common contents in
> > > the powerpc implementation.
> > 
> > parisc in this case.
> > 
> 
> Fixed, thanks!

Actually, after the comment about just removing the gen_rtc driver
in the long run, I checked again and found that PARISC unconditionally
selects RTC_CLASS, so this driver can't even be built here.
We should just remove the header and drop PARISC from the list.

If we also drop m68k, that just leaves powerpc.

	Arnd

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Arnd Bergmann]

On Wednesday 27 April 2016 13:21:16 Arnd Bergmann wrote:
> On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
> > Arnd Bergmann wrote:
> > > The asm-generic/rtc.h header can now be included by
> > > architectures that provide their own set_rtc_time/get_rtc_time
> > > macros, letting us remove most of the common contents in
> > > the powerpc implementation.
> > 
> > parisc in this case.
> > 
> 
> Fixed, thanks!

Actually, after the comment about just removing the gen_rtc driver
in the long run, I checked again and found that PARISC unconditionally
selects RTC_CLASS, so this driver can't even be built here.
We should just remove the header and drop PARISC from the list.

If we also drop m68k, that just leaves powerpc.

	Arnd

Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Geert Uytterhoeven]

On Wed, Apr 27, 2016 at 1:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 27 April 2016 13:21:16 Arnd Bergmann wrote:
>> On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
>> > Arnd Bergmann wrote:
>> > > The asm-generic/rtc.h header can now be included by
>> > > architectures that provide their own set_rtc_time/get_rtc_time
>> > > macros, letting us remove most of the common contents in
>> > > the powerpc implementation.
>> >
>> > parisc in this case.
>> >
>>
>> Fixed, thanks!
>
> Actually, after the comment about just removing the gen_rtc driver
> in the long run, I checked again and found that PARISC unconditionally
> selects RTC_CLASS, so this driver can't even be built here.
> We should just remove the header and drop PARISC from the list.
>
> If we also drop m68k, that just leaves powerpc.

I've just checked Debian's unofficial linux-image-4.5.0-1-m68k_4.5.1-1_m68k,
and it also enables RTC_CLASS and CONFIG_RTC_DRV_GENERIC, so gen_rtc
can be dropped on m68k for sure.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Geert Uytterhoeven]

On Wed, Apr 27, 2016 at 1:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 27 April 2016 13:21:16 Arnd Bergmann wrote:
>> On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
>> > Arnd Bergmann wrote:
>> > > The asm-generic/rtc.h header can now be included by
>> > > architectures that provide their own set_rtc_time/get_rtc_time
>> > > macros, letting us remove most of the common contents in
>> > > the powerpc implementation.
>> >
>> > parisc in this case.
>> >
>>
>> Fixed, thanks!
>
> Actually, after the comment about just removing the gen_rtc driver
> in the long run, I checked again and found that PARISC unconditionally
> selects RTC_CLASS, so this driver can't even be built here.
> We should just remove the header and drop PARISC from the list.
>
> If we also drop m68k, that just leaves powerpc.

I've just checked Debian's unofficial linux-image-4.5.0-1-m68k_4.5.1-1_m68k,
and it also enables RTC_CLASS and CONFIG_RTC_DRV_GENERIC, so gen_rtc
can be dropped on m68k for sure.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[rtc-linux] Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Geert Uytterhoeven]

On Wed, Apr 27, 2016 at 1:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 27 April 2016 13:21:16 Arnd Bergmann wrote:
>> On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
>> > Arnd Bergmann wrote:
>> > > The asm-generic/rtc.h header can now be included by
>> > > architectures that provide their own set_rtc_time/get_rtc_time
>> > > macros, letting us remove most of the common contents in
>> > > the powerpc implementation.
>> >
>> > parisc in this case.
>> >
>>
>> Fixed, thanks!
>
> Actually, after the comment about just removing the gen_rtc driver
> in the long run, I checked again and found that PARISC unconditionally
> selects RTC_CLASS, so this driver can't even be built here.
> We should just remove the header and drop PARISC from the list.
>
> If we also drop m68k, that just leaves powerpc.

I've just checked Debian's unofficial linux-image-4.5.0-1-m68k_4.5.1-1_m68k,
and it also enables RTC_CLASS and CONFIG_RTC_DRV_GENERIC, so gen_rtc
can be dropped on m68k for sure.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Geert Uytterhoeven]

On Wed, Apr 27, 2016 at 1:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 27 April 2016 13:21:16 Arnd Bergmann wrote:
>> On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
>> > Arnd Bergmann wrote:
>> > > The asm-generic/rtc.h header can now be included by
>> > > architectures that provide their own set_rtc_time/get_rtc_time
>> > > macros, letting us remove most of the common contents in
>> > > the powerpc implementation.
>> >
>> > parisc in this case.
>> >
>>
>> Fixed, thanks!
>
> Actually, after the comment about just removing the gen_rtc driver
> in the long run, I checked again and found that PARISC unconditionally
> selects RTC_CLASS, so this driver can't even be built here.
> We should just remove the header and drop PARISC from the list.
>
> If we also drop m68k, that just leaves powerpc.

I've just checked Debian's unofficial linux-image-4.5.0-1-m68k_4.5.1-1_m68k,
and it also enables RTC_CLASS and CONFIG_RTC_DRV_GENERIC, so gen_rtc
can be dropped on m68k for sure.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Geert Uytterhoeven]

On Wed, Apr 27, 2016 at 1:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 27 April 2016 13:21:16 Arnd Bergmann wrote:
>> On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
>> > Arnd Bergmann wrote:
>> > > The asm-generic/rtc.h header can now be included by
>> > > architectures that provide their own set_rtc_time/get_rtc_time
>> > > macros, letting us remove most of the common contents in
>> > > the powerpc implementation.
>> >
>> > parisc in this case.
>> >
>>
>> Fixed, thanks!
>
> Actually, after the comment about just removing the gen_rtc driver
> in the long run, I checked again and found that PARISC unconditionally
> selects RTC_CLASS, so this driver can't even be built here.
> We should just remove the header and drop PARISC from the list.
>
> If we also drop m68k, that just leaves powerpc.

I've just checked Debian's unofficial linux-image-4.5.0-1-m68k_4.5.1-1_m68k,
and it also enables RTC_CLASS and CONFIG_RTC_DRV_GENERIC, so gen_rtc
can be dropped on m68k for sure.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Arnd Bergmann]

On Wednesday 27 April 2016 13:55:43 Geert Uytterhoeven wrote:
> On Wed, Apr 27, 2016 at 1:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday 27 April 2016 13:21:16 Arnd Bergmann wrote:
> >> On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
> >> > Arnd Bergmann wrote:
> >> > > The asm-generic/rtc.h header can now be included by
> >> > > architectures that provide their own set_rtc_time/get_rtc_time
> >> > > macros, letting us remove most of the common contents in
> >> > > the powerpc implementation.
> >> >
> >> > parisc in this case.
> >> >
> >>
> >> Fixed, thanks!
> >
> > Actually, after the comment about just removing the gen_rtc driver
> > in the long run, I checked again and found that PARISC unconditionally
> > selects RTC_CLASS, so this driver can't even be built here.
> > We should just remove the header and drop PARISC from the list.
> >
> > If we also drop m68k, that just leaves powerpc.
> 
> I've just checked Debian's unofficial linux-image-4.5.0-1-m68k_4.5.1-1_m68k,
> and it also enables RTC_CLASS and CONFIG_RTC_DRV_GENERIC, so gen_rtc
> can be dropped on m68k for sure.

Ok, excellent. I'll try to rework the series then to completely eliminate
the driver (or leaving it ppc-only).

	Arnd

Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Arnd Bergmann]

On Wednesday 27 April 2016 13:55:43 Geert Uytterhoeven wrote:
> On Wed, Apr 27, 2016 at 1:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday 27 April 2016 13:21:16 Arnd Bergmann wrote:
> >> On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
> >> > Arnd Bergmann wrote:
> >> > > The asm-generic/rtc.h header can now be included by
> >> > > architectures that provide their own set_rtc_time/get_rtc_time
> >> > > macros, letting us remove most of the common contents in
> >> > > the powerpc implementation.
> >> >
> >> > parisc in this case.
> >> >
> >>
> >> Fixed, thanks!
> >
> > Actually, after the comment about just removing the gen_rtc driver
> > in the long run, I checked again and found that PARISC unconditionally
> > selects RTC_CLASS, so this driver can't even be built here.
> > We should just remove the header and drop PARISC from the list.
> >
> > If we also drop m68k, that just leaves powerpc.
> 
> I've just checked Debian's unofficial linux-image-4.5.0-1-m68k_4.5.1-1_m68k,
> and it also enables RTC_CLASS and CONFIG_RTC_DRV_GENERIC, so gen_rtc
> can be dropped on m68k for sure.

Ok, excellent. I'll try to rework the series then to completely eliminate
the driver (or leaving it ppc-only).

	Arnd

[rtc-linux] Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Arnd Bergmann]

On Wednesday 27 April 2016 13:55:43 Geert Uytterhoeven wrote:
> On Wed, Apr 27, 2016 at 1:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday 27 April 2016 13:21:16 Arnd Bergmann wrote:
> >> On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
> >> > Arnd Bergmann wrote:
> >> > > The asm-generic/rtc.h header can now be included by
> >> > > architectures that provide their own set_rtc_time/get_rtc_time
> >> > > macros, letting us remove most of the common contents in
> >> > > the powerpc implementation.
> >> >
> >> > parisc in this case.
> >> >
> >>
> >> Fixed, thanks!
> >
> > Actually, after the comment about just removing the gen_rtc driver
> > in the long run, I checked again and found that PARISC unconditionally
> > selects RTC_CLASS, so this driver can't even be built here.
> > We should just remove the header and drop PARISC from the list.
> >
> > If we also drop m68k, that just leaves powerpc.
> 
> I've just checked Debian's unofficial linux-image-4.5.0-1-m68k_4.5.1-1_m68k,
> and it also enables RTC_CLASS and CONFIG_RTC_DRV_GENERIC, so gen_rtc
> can be dropped on m68k for sure.

Ok, excellent. I'll try to rework the series then to completely eliminate
the driver (or leaving it ppc-only).

	Arnd

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Arnd Bergmann]

On Wednesday 27 April 2016 13:55:43 Geert Uytterhoeven wrote:
> On Wed, Apr 27, 2016 at 1:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday 27 April 2016 13:21:16 Arnd Bergmann wrote:
> >> On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
> >> > Arnd Bergmann wrote:
> >> > > The asm-generic/rtc.h header can now be included by
> >> > > architectures that provide their own set_rtc_time/get_rtc_time
> >> > > macros, letting us remove most of the common contents in
> >> > > the powerpc implementation.
> >> >
> >> > parisc in this case.
> >> >
> >>
> >> Fixed, thanks!
> >
> > Actually, after the comment about just removing the gen_rtc driver
> > in the long run, I checked again and found that PARISC unconditionally
> > selects RTC_CLASS, so this driver can't even be built here.
> > We should just remove the header and drop PARISC from the list.
> >
> > If we also drop m68k, that just leaves powerpc.
> 
> I've just checked Debian's unofficial linux-image-4.5.0-1-m68k_4.5.1-1_m68k,
> and it also enables RTC_CLASS and CONFIG_RTC_DRV_GENERIC, so gen_rtc
> can be dropped on m68k for sure.

Ok, excellent. I'll try to rework the series then to completely eliminate
the driver (or leaving it ppc-only).

	Arnd

Re: [PATCH 6/8] char/genrtc: parisc: use asm-generic/rtc.h

[Arnd Bergmann]

On Wednesday 27 April 2016 13:55:43 Geert Uytterhoeven wrote:
> On Wed, Apr 27, 2016 at 1:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday 27 April 2016 13:21:16 Arnd Bergmann wrote:
> >> On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
> >> > Arnd Bergmann wrote:
> >> > > The asm-generic/rtc.h header can now be included by
> >> > > architectures that provide their own set_rtc_time/get_rtc_time
> >> > > macros, letting us remove most of the common contents in
> >> > > the powerpc implementation.
> >> >
> >> > parisc in this case.
> >> >
> >>
> >> Fixed, thanks!
> >
> > Actually, after the comment about just removing the gen_rtc driver
> > in the long run, I checked again and found that PARISC unconditionally
> > selects RTC_CLASS, so this driver can't even be built here.
> > We should just remove the header and drop PARISC from the list.
> >
> > If we also drop m68k, that just leaves powerpc.
> 
> I've just checked Debian's unofficial linux-image-4.5.0-1-m68k_4.5.1-1_m68k,
> and it also enables RTC_CLASS and CONFIG_RTC_DRV_GENERIC, so gen_rtc
> can be dropped on m68k for sure.

Ok, excellent. I'll try to rework the series then to completely eliminate
the driver (or leaving it ppc-only).

	Arnd

[PATCH 7/8] char/genrtc: disallow building on Alpha

[Arnd Bergmann]

The genrtc driver serves no purpose on Alpha because it drives the
same hardware as the original rtc.c driver, and the newer rtc-generic.c
or rtc-cmos.c drivers on architectures that use the asm-generic/rtc.h
header.

The defconfig uses CONFIG_RTC=y, so this driver is not used by default.
At one point it was used to abstract a quirk for the "Marvel" platform,
but it does not do this any more after the code was moved into yet
another driver in arch/alpha/kernel/rtc.c.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/char/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 9bdb629fbaae..697510325b1d 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -328,7 +328,7 @@ config JS_RTC
 config GEN_RTC
 	tristate "Generic /dev/rtc emulation"
 	depends on RTC!=y
-	depends on ALPHA || M68K || MN10300 || PARISC || PPC
+	depends on M68K || MN10300 || PARISC || PPC
 	---help---
 	  If you say Y here and create a character special file /dev/rtc with
 	  major number 10 and minor number 135 using mknod ("man mknod"), you
-- 
2.7.0

[rtc-linux] [PATCH 7/8] char/genrtc: disallow building on Alpha

[Arnd Bergmann]

The genrtc driver serves no purpose on Alpha because it drives the
same hardware as the original rtc.c driver, and the newer rtc-generic.c
or rtc-cmos.c drivers on architectures that use the asm-generic/rtc.h
header.

The defconfig uses CONFIG_RTC=y, so this driver is not used by default.
At one point it was used to abstract a quirk for the "Marvel" platform,
but it does not do this any more after the code was moved into yet
another driver in arch/alpha/kernel/rtc.c.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/char/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 9bdb629fbaae..697510325b1d 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -328,7 +328,7 @@ config JS_RTC
 config GEN_RTC
 	tristate "Generic /dev/rtc emulation"
 	depends on RTC!=y
-	depends on ALPHA || M68K || MN10300 || PARISC || PPC
+	depends on M68K || MN10300 || PARISC || PPC
 	---help---
 	  If you say Y here and create a character special file /dev/rtc with
 	  major number 10 and minor number 135 using mknod ("man mknod"), you
-- 
2.7.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PATCH 7/8] char/genrtc: disallow building on Alpha

[Arnd Bergmann]

The genrtc driver serves no purpose on Alpha because it drives the
same hardware as the original rtc.c driver, and the newer rtc-generic.c
or rtc-cmos.c drivers on architectures that use the asm-generic/rtc.h
header.

The defconfig uses CONFIG_RTC=y, so this driver is not used by default.
At one point it was used to abstract a quirk for the "Marvel" platform,
but it does not do this any more after the code was moved into yet
another driver in arch/alpha/kernel/rtc.c.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/char/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 9bdb629fbaae..697510325b1d 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -328,7 +328,7 @@ config JS_RTC
 config GEN_RTC
 	tristate "Generic /dev/rtc emulation"
 	depends on RTC!=y
-	depends on ALPHA || M68K || MN10300 || PARISC || PPC
+	depends on M68K || MN10300 || PARISC || PPC
 	---help---
 	  If you say Y here and create a character special file /dev/rtc with
 	  major number 10 and minor number 135 using mknod ("man mknod"), you
-- 
2.7.0

[PATCH 8/8] char/genrtc: disallow building on mn10300

[Arnd Bergmann]

The genrtc driver serves no purpose on mn10300 because it drives the
same hardware as the original rtc.c driver, and the newer rtc-generic.c
or rtc-cmos.c drivers on architectures that use the asm-generic/rtc.h
header.

I assume it was initially only added for completeness when the
mn10300 port was done, but the older rtc.c driver was always used
instead.

It would be nice to change the architecture to use the rtc-cmos driver
next, and remove support for the old rtc driver as well.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/char/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 697510325b1d..d17ed90ebc82 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -328,7 +328,7 @@ config JS_RTC
 config GEN_RTC
 	tristate "Generic /dev/rtc emulation"
 	depends on RTC!=y
-	depends on M68K || MN10300 || PARISC || PPC
+	depends on M68K || PARISC || PPC
 	---help---
 	  If you say Y here and create a character special file /dev/rtc with
 	  major number 10 and minor number 135 using mknod ("man mknod"), you
-- 
2.7.0

[rtc-linux] [PATCH 8/8] char/genrtc: disallow building on mn10300

[Arnd Bergmann]

The genrtc driver serves no purpose on mn10300 because it drives the
same hardware as the original rtc.c driver, and the newer rtc-generic.c
or rtc-cmos.c drivers on architectures that use the asm-generic/rtc.h
header.

I assume it was initially only added for completeness when the
mn10300 port was done, but the older rtc.c driver was always used
instead.

It would be nice to change the architecture to use the rtc-cmos driver
next, and remove support for the old rtc driver as well.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/char/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 697510325b1d..d17ed90ebc82 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -328,7 +328,7 @@ config JS_RTC
 config GEN_RTC
 	tristate "Generic /dev/rtc emulation"
 	depends on RTC!=y
-	depends on M68K || MN10300 || PARISC || PPC
+	depends on M68K || PARISC || PPC
 	---help---
 	  If you say Y here and create a character special file /dev/rtc with
 	  major number 10 and minor number 135 using mknod ("man mknod"), you
-- 
2.7.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PATCH 8/8] char/genrtc: disallow building on mn10300

[Arnd Bergmann]

The genrtc driver serves no purpose on mn10300 because it drives the
same hardware as the original rtc.c driver, and the newer rtc-generic.c
or rtc-cmos.c drivers on architectures that use the asm-generic/rtc.h
header.

I assume it was initially only added for completeness when the
mn10300 port was done, but the older rtc.c driver was always used
instead.

It would be nice to change the architecture to use the rtc-cmos driver
next, and remove support for the old rtc driver as well.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/char/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 697510325b1d..d17ed90ebc82 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -328,7 +328,7 @@ config JS_RTC
 config GEN_RTC
 	tristate "Generic /dev/rtc emulation"
 	depends on RTC!=y
-	depends on M68K || MN10300 || PARISC || PPC
+	depends on M68K || PARISC || PPC
 	---help---
 	  If you say Y here and create a character special file /dev/rtc with
 	  major number 10 and minor number 135 using mknod ("man mknod"), you
-- 
2.7.0

Re: char: legacy RTC cleanups

[Geert Uytterhoeven]

Hi Arnd,

On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> For the genrtc driver, rearranging the headers makes it simpler
> to use and reduces duplication. In case of alpha and mn10300,
> I've shown that the genrtc and rtc drivers are doing the same
> thing, so we don't need them both. The remaining three
> architectures (m68k, parisc, powerpc) actually all support
> the newer rtc-generic driver, so we could remove genrtc completely
> if we want to.

CONFIG_GEN_RTC is not enabled in any of the m68k defconfigs, so I think genrtc
has been unused for a while.
All defconfigs either use CONFIG_RTC_DRV_GENERIC, or enable a more specific
RTC driver.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: char: legacy RTC cleanups

[Geert Uytterhoeven]

Hi Arnd,

On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> For the genrtc driver, rearranging the headers makes it simpler
> to use and reduces duplication. In case of alpha and mn10300,
> I've shown that the genrtc and rtc drivers are doing the same
> thing, so we don't need them both. The remaining three
> architectures (m68k, parisc, powerpc) actually all support
> the newer rtc-generic driver, so we could remove genrtc completely
> if we want to.

CONFIG_GEN_RTC is not enabled in any of the m68k defconfigs, so I think genrtc
has been unused for a while.
All defconfigs either use CONFIG_RTC_DRV_GENERIC, or enable a more specific
RTC driver.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[rtc-linux] Re: char: legacy RTC cleanups

[Geert Uytterhoeven]

Hi Arnd,

On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> For the genrtc driver, rearranging the headers makes it simpler
> to use and reduces duplication. In case of alpha and mn10300,
> I've shown that the genrtc and rtc drivers are doing the same
> thing, so we don't need them both. The remaining three
> architectures (m68k, parisc, powerpc) actually all support
> the newer rtc-generic driver, so we could remove genrtc completely
> if we want to.

CONFIG_GEN_RTC is not enabled in any of the m68k defconfigs, so I think genrtc
has been unused for a while.
All defconfigs either use CONFIG_RTC_DRV_GENERIC, or enable a more specific
RTC driver.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: char: legacy RTC cleanups

[Geert Uytterhoeven]

Hi Arnd,

On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> For the genrtc driver, rearranging the headers makes it simpler
> to use and reduces duplication. In case of alpha and mn10300,
> I've shown that the genrtc and rtc drivers are doing the same
> thing, so we don't need them both. The remaining three
> architectures (m68k, parisc, powerpc) actually all support
> the newer rtc-generic driver, so we could remove genrtc completely
> if we want to.

CONFIG_GEN_RTC is not enabled in any of the m68k defconfigs, so I think genrtc
has been unused for a while.
All defconfigs either use CONFIG_RTC_DRV_GENERIC, or enable a more specific
RTC driver.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: char: legacy RTC cleanups

[Geert Uytterhoeven]

Hi Arnd,

On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> For the genrtc driver, rearranging the headers makes it simpler
> to use and reduces duplication. In case of alpha and mn10300,
> I've shown that the genrtc and rtc drivers are doing the same
> thing, so we don't need them both. The remaining three
> architectures (m68k, parisc, powerpc) actually all support
> the newer rtc-generic driver, so we could remove genrtc completely
> if we want to.

CONFIG_GEN_RTC is not enabled in any of the m68k defconfigs, so I think genrtc
has been unused for a while.
All defconfigs either use CONFIG_RTC_DRV_GENERIC, or enable a more specific
RTC driver.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: char: legacy RTC cleanups

[Arnd Bergmann]

On Wednesday 27 April 2016 09:54:41 Geert Uytterhoeven wrote:
> Hi Arnd,
> 
> On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > For the genrtc driver, rearranging the headers makes it simpler
> > to use and reduces duplication. In case of alpha and mn10300,
> > I've shown that the genrtc and rtc drivers are doing the same
> > thing, so we don't need them both. The remaining three
> > architectures (m68k, parisc, powerpc) actually all support
> > the newer rtc-generic driver, so we could remove genrtc completely
> > if we want to.
> 
> CONFIG_GEN_RTC is not enabled in any of the m68k defconfigs, so I think genrtc
> has been unused for a while.
> All defconfigs either use CONFIG_RTC_DRV_GENERIC, or enable a more specific
> RTC driver.

Ok, good to know. I'm guessing the same is true for parisc, but there are
also very few users.

Regarding the Q40 specific ioctls, what do you think this means, is it

a) nobody uses Q40 with modern kernels,
b) nobody calls RTC_PLL_GET/RTC_PLL_SET on q40, or
c) Q40 users have their own configurations and enable GEN_RTC?

On powerpc, a quarter of the defconfigs (mostly for really old hardware)
still use GEN_RTC, but I guess we can either bulk-convert them to RTC_GENERIC,
or convert the five implementations of .get_rtc_time/.set_rtc_time
(8xx, rtas, chrp, powermac, maple) into five regular RTC class drivers.

	Arnd

Re: char: legacy RTC cleanups

[Arnd Bergmann]

On Wednesday 27 April 2016 09:54:41 Geert Uytterhoeven wrote:
> Hi Arnd,
> 
> On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > For the genrtc driver, rearranging the headers makes it simpler
> > to use and reduces duplication. In case of alpha and mn10300,
> > I've shown that the genrtc and rtc drivers are doing the same
> > thing, so we don't need them both. The remaining three
> > architectures (m68k, parisc, powerpc) actually all support
> > the newer rtc-generic driver, so we could remove genrtc completely
> > if we want to.
> 
> CONFIG_GEN_RTC is not enabled in any of the m68k defconfigs, so I think genrtc
> has been unused for a while.
> All defconfigs either use CONFIG_RTC_DRV_GENERIC, or enable a more specific
> RTC driver.

Ok, good to know. I'm guessing the same is true for parisc, but there are
also very few users.

Regarding the Q40 specific ioctls, what do you think this means, is it

a) nobody uses Q40 with modern kernels,
b) nobody calls RTC_PLL_GET/RTC_PLL_SET on q40, or
c) Q40 users have their own configurations and enable GEN_RTC?

On powerpc, a quarter of the defconfigs (mostly for really old hardware)
still use GEN_RTC, but I guess we can either bulk-convert them to RTC_GENERIC,
or convert the five implementations of .get_rtc_time/.set_rtc_time
(8xx, rtas, chrp, powermac, maple) into five regular RTC class drivers.

	Arnd

Re: char: legacy RTC cleanups

[Arnd Bergmann]

On Wednesday 27 April 2016 09:54:41 Geert Uytterhoeven wrote:
> Hi Arnd,
> 
> On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > For the genrtc driver, rearranging the headers makes it simpler
> > to use and reduces duplication. In case of alpha and mn10300,
> > I've shown that the genrtc and rtc drivers are doing the same
> > thing, so we don't need them both. The remaining three
> > architectures (m68k, parisc, powerpc) actually all support
> > the newer rtc-generic driver, so we could remove genrtc completely
> > if we want to.
> 
> CONFIG_GEN_RTC is not enabled in any of the m68k defconfigs, so I think genrtc
> has been unused for a while.
> All defconfigs either use CONFIG_RTC_DRV_GENERIC, or enable a more specific
> RTC driver.

Ok, good to know. I'm guessing the same is true for parisc, but there are
also very few users.

Regarding the Q40 specific ioctls, what do you think this means, is it

a) nobody uses Q40 with modern kernels,
b) nobody calls RTC_PLL_GET/RTC_PLL_SET on q40, or
c) Q40 users have their own configurations and enable GEN_RTC?

On powerpc, a quarter of the defconfigs (mostly for really old hardware)
still use GEN_RTC, but I guess we can either bulk-convert them to RTC_GENERIC,
or convert the five implementations of .get_rtc_time/.set_rtc_time
(8xx, rtas, chrp, powermac, maple) into five regular RTC class drivers.

	Arnd

[rtc-linux] Re: char: legacy RTC cleanups

[Arnd Bergmann]

On Wednesday 27 April 2016 09:54:41 Geert Uytterhoeven wrote:
> Hi Arnd,
> 
> On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > For the genrtc driver, rearranging the headers makes it simpler
> > to use and reduces duplication. In case of alpha and mn10300,
> > I've shown that the genrtc and rtc drivers are doing the same
> > thing, so we don't need them both. The remaining three
> > architectures (m68k, parisc, powerpc) actually all support
> > the newer rtc-generic driver, so we could remove genrtc completely
> > if we want to.
> 
> CONFIG_GEN_RTC is not enabled in any of the m68k defconfigs, so I think genrtc
> has been unused for a while.
> All defconfigs either use CONFIG_RTC_DRV_GENERIC, or enable a more specific
> RTC driver.

Ok, good to know. I'm guessing the same is true for parisc, but there are
also very few users.

Regarding the Q40 specific ioctls, what do you think this means, is it

a) nobody uses Q40 with modern kernels,
b) nobody calls RTC_PLL_GET/RTC_PLL_SET on q40, or
c) Q40 users have their own configurations and enable GEN_RTC?

On powerpc, a quarter of the defconfigs (mostly for really old hardware)
still use GEN_RTC, but I guess we can either bulk-convert them to RTC_GENERIC,
or convert the five implementations of .get_rtc_time/.set_rtc_time
(8xx, rtas, chrp, powermac, maple) into five regular RTC class drivers.

	Arnd

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: char: legacy RTC cleanups

[Arnd Bergmann]

On Wednesday 27 April 2016 09:54:41 Geert Uytterhoeven wrote:
> Hi Arnd,
> 
> On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > For the genrtc driver, rearranging the headers makes it simpler
> > to use and reduces duplication. In case of alpha and mn10300,
> > I've shown that the genrtc and rtc drivers are doing the same
> > thing, so we don't need them both. The remaining three
> > architectures (m68k, parisc, powerpc) actually all support
> > the newer rtc-generic driver, so we could remove genrtc completely
> > if we want to.
> 
> CONFIG_GEN_RTC is not enabled in any of the m68k defconfigs, so I think genrtc
> has been unused for a while.
> All defconfigs either use CONFIG_RTC_DRV_GENERIC, or enable a more specific
> RTC driver.

Ok, good to know. I'm guessing the same is true for parisc, but there are
also very few users.

Regarding the Q40 specific ioctls, what do you think this means, is it

a) nobody uses Q40 with modern kernels,
b) nobody calls RTC_PLL_GET/RTC_PLL_SET on q40, or
c) Q40 users have their own configurations and enable GEN_RTC?

On powerpc, a quarter of the defconfigs (mostly for really old hardware)
still use GEN_RTC, but I guess we can either bulk-convert them to RTC_GENERIC,
or convert the five implementations of .get_rtc_time/.set_rtc_time
(8xx, rtas, chrp, powermac, maple) into five regular RTC class drivers.

	Arnd

Re: char: legacy RTC cleanups

[Arnd Bergmann]

On Wednesday 27 April 2016 09:54:41 Geert Uytterhoeven wrote:
> Hi Arnd,
> 
> On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > For the genrtc driver, rearranging the headers makes it simpler
> > to use and reduces duplication. In case of alpha and mn10300,
> > I've shown that the genrtc and rtc drivers are doing the same
> > thing, so we don't need them both. The remaining three
> > architectures (m68k, parisc, powerpc) actually all support
> > the newer rtc-generic driver, so we could remove genrtc completely
> > if we want to.
> 
> CONFIG_GEN_RTC is not enabled in any of the m68k defconfigs, so I think genrtc
> has been unused for a while.
> All defconfigs either use CONFIG_RTC_DRV_GENERIC, or enable a more specific
> RTC driver.

Ok, good to know. I'm guessing the same is true for parisc, but there are
also very few users.

Regarding the Q40 specific ioctls, what do you think this means, is it

a) nobody uses Q40 with modern kernels,
b) nobody calls RTC_PLL_GET/RTC_PLL_SET on q40, or
c) Q40 users have their own configurations and enable GEN_RTC?

On powerpc, a quarter of the defconfigs (mostly for really old hardware)
still use GEN_RTC, but I guess we can either bulk-convert them to RTC_GENERIC,
or convert the five implementations of .get_rtc_time/.set_rtc_time
(8xx, rtas, chrp, powermac, maple) into five regular RTC class drivers.

	Arnd

Re: char: legacy RTC cleanups

[Geert Uytterhoeven]

Hi Arnd,

On Wed, Apr 27, 2016 at 10:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 27 April 2016 09:54:41 Geert Uytterhoeven wrote:
>> On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > For the genrtc driver, rearranging the headers makes it simpler
>> > to use and reduces duplication. In case of alpha and mn10300,
>> > I've shown that the genrtc and rtc drivers are doing the same
>> > thing, so we don't need them both. The remaining three
>> > architectures (m68k, parisc, powerpc) actually all support
>> > the newer rtc-generic driver, so we could remove genrtc completely
>> > if we want to.
>>
>> CONFIG_GEN_RTC is not enabled in any of the m68k defconfigs, so I think genrtc
>> has been unused for a while.
>> All defconfigs either use CONFIG_RTC_DRV_GENERIC, or enable a more specific
>> RTC driver.
>
> Ok, good to know. I'm guessing the same is true for parisc, but there are
> also very few users.
>
> Regarding the Q40 specific ioctls, what do you think this means, is it
>
> a) nobody uses Q40 with modern kernels,
> b) nobody calls RTC_PLL_GET/RTC_PLL_SET on q40, or
> c) Q40 users have their own configurations and enable GEN_RTC?

To be honest, I have no idea. There have never been many Q40 users.
(old) http://www.linux-m68k.org/Registry/Statistics.html shows only 8.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: char: legacy RTC cleanups

[Geert Uytterhoeven]

Hi Arnd,

On Wed, Apr 27, 2016 at 10:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 27 April 2016 09:54:41 Geert Uytterhoeven wrote:
>> On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > For the genrtc driver, rearranging the headers makes it simpler
>> > to use and reduces duplication. In case of alpha and mn10300,
>> > I've shown that the genrtc and rtc drivers are doing the same
>> > thing, so we don't need them both. The remaining three
>> > architectures (m68k, parisc, powerpc) actually all support
>> > the newer rtc-generic driver, so we could remove genrtc completely
>> > if we want to.
>>
>> CONFIG_GEN_RTC is not enabled in any of the m68k defconfigs, so I think genrtc
>> has been unused for a while.
>> All defconfigs either use CONFIG_RTC_DRV_GENERIC, or enable a more specific
>> RTC driver.
>
> Ok, good to know. I'm guessing the same is true for parisc, but there are
> also very few users.
>
> Regarding the Q40 specific ioctls, what do you think this means, is it
>
> a) nobody uses Q40 with modern kernels,
> b) nobody calls RTC_PLL_GET/RTC_PLL_SET on q40, or
> c) Q40 users have their own configurations and enable GEN_RTC?

To be honest, I have no idea. There have never been many Q40 users.
(old) http://www.linux-m68k.org/Registry/Statistics.html shows only 8.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[rtc-linux] Re: char: legacy RTC cleanups

[Geert Uytterhoeven]

Hi Arnd,

On Wed, Apr 27, 2016 at 10:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 27 April 2016 09:54:41 Geert Uytterhoeven wrote:
>> On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > For the genrtc driver, rearranging the headers makes it simpler
>> > to use and reduces duplication. In case of alpha and mn10300,
>> > I've shown that the genrtc and rtc drivers are doing the same
>> > thing, so we don't need them both. The remaining three
>> > architectures (m68k, parisc, powerpc) actually all support
>> > the newer rtc-generic driver, so we could remove genrtc completely
>> > if we want to.
>>
>> CONFIG_GEN_RTC is not enabled in any of the m68k defconfigs, so I think genrtc
>> has been unused for a while.
>> All defconfigs either use CONFIG_RTC_DRV_GENERIC, or enable a more specific
>> RTC driver.
>
> Ok, good to know. I'm guessing the same is true for parisc, but there are
> also very few users.
>
> Regarding the Q40 specific ioctls, what do you think this means, is it
>
> a) nobody uses Q40 with modern kernels,
> b) nobody calls RTC_PLL_GET/RTC_PLL_SET on q40, or
> c) Q40 users have their own configurations and enable GEN_RTC?

To be honest, I have no idea. There have never been many Q40 users.
(old) http://www.linux-m68k.org/Registry/Statistics.html shows only 8.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: char: legacy RTC cleanups

[Geert Uytterhoeven]

Hi Arnd,

On Wed, Apr 27, 2016 at 10:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 27 April 2016 09:54:41 Geert Uytterhoeven wrote:
>> On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > For the genrtc driver, rearranging the headers makes it simpler
>> > to use and reduces duplication. In case of alpha and mn10300,
>> > I've shown that the genrtc and rtc drivers are doing the same
>> > thing, so we don't need them both. The remaining three
>> > architectures (m68k, parisc, powerpc) actually all support
>> > the newer rtc-generic driver, so we could remove genrtc completely
>> > if we want to.
>>
>> CONFIG_GEN_RTC is not enabled in any of the m68k defconfigs, so I think genrtc
>> has been unused for a while.
>> All defconfigs either use CONFIG_RTC_DRV_GENERIC, or enable a more specific
>> RTC driver.
>
> Ok, good to know. I'm guessing the same is true for parisc, but there are
> also very few users.
>
> Regarding the Q40 specific ioctls, what do you think this means, is it
>
> a) nobody uses Q40 with modern kernels,
> b) nobody calls RTC_PLL_GET/RTC_PLL_SET on q40, or
> c) Q40 users have their own configurations and enable GEN_RTC?

To be honest, I have no idea. There have never been many Q40 users.
(old) http://www.linux-m68k.org/Registry/Statistics.html shows only 8.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: char: legacy RTC cleanups

[Geert Uytterhoeven]

Hi Arnd,

On Wed, Apr 27, 2016 at 10:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 27 April 2016 09:54:41 Geert Uytterhoeven wrote:
>> On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > For the genrtc driver, rearranging the headers makes it simpler
>> > to use and reduces duplication. In case of alpha and mn10300,
>> > I've shown that the genrtc and rtc drivers are doing the same
>> > thing, so we don't need them both. The remaining three
>> > architectures (m68k, parisc, powerpc) actually all support
>> > the newer rtc-generic driver, so we could remove genrtc completely
>> > if we want to.
>>
>> CONFIG_GEN_RTC is not enabled in any of the m68k defconfigs, so I think genrtc
>> has been unused for a while.
>> All defconfigs either use CONFIG_RTC_DRV_GENERIC, or enable a more specific
>> RTC driver.
>
> Ok, good to know. I'm guessing the same is true for parisc, but there are
> also very few users.
>
> Regarding the Q40 specific ioctls, what do you think this means, is it
>
> a) nobody uses Q40 with modern kernels,
> b) nobody calls RTC_PLL_GET/RTC_PLL_SET on q40, or
> c) Q40 users have their own configurations and enable GEN_RTC?

To be honest, I have no idea. There have never been many Q40 users.
(old) http://www.linux-m68k.org/Registry/Statistics.html shows only 8.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: char: legacy RTC cleanups

[Alexandre Belloni]

On 26/04/2016 at 23:44:04 +0200, Arnd Bergmann wrote :
> I've had these patches in my tree for a while, after the first one
> had a few issues that are fixed in this new version. The old-style
> PC RTC driver is now also disabled on m68k (as pointed out by
> Geert), ppc (it was also blacklisted), and m32r (I showed that
> it did not build).
> 
> For the genrtc driver, rearranging the headers makes it simpler
> to use and reduces duplication. In case of alpha and mn10300,
> I've shown that the genrtc and rtc drivers are doing the same
> thing, so we don't need them both. The remaining three
> architectures (m68k, parisc, powerpc) actually all support
> the newer rtc-generic driver, so we could remove genrtc completely
> if we want to.
> 

Personally, I'd go for the kill and remove genrtc instead of cleaning it
up.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[rtc-linux] Re: char: legacy RTC cleanups

[Alexandre Belloni]

On 26/04/2016 at 23:44:04 +0200, Arnd Bergmann wrote :
> I've had these patches in my tree for a while, after the first one
> had a few issues that are fixed in this new version. The old-style
> PC RTC driver is now also disabled on m68k (as pointed out by
> Geert), ppc (it was also blacklisted), and m32r (I showed that
> it did not build).
> 
> For the genrtc driver, rearranging the headers makes it simpler
> to use and reduces duplication. In case of alpha and mn10300,
> I've shown that the genrtc and rtc drivers are doing the same
> thing, so we don't need them both. The remaining three
> architectures (m68k, parisc, powerpc) actually all support
> the newer rtc-generic driver, so we could remove genrtc completely
> if we want to.
> 

Personally, I'd go for the kill and remove genrtc instead of cleaning it
up.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: char: legacy RTC cleanups

[Alexandre Belloni]

On 26/04/2016 at 23:44:04 +0200, Arnd Bergmann wrote :
> I've had these patches in my tree for a while, after the first one
> had a few issues that are fixed in this new version. The old-style
> PC RTC driver is now also disabled on m68k (as pointed out by
> Geert), ppc (it was also blacklisted), and m32r (I showed that
> it did not build).
> 
> For the genrtc driver, rearranging the headers makes it simpler
> to use and reduces duplication. In case of alpha and mn10300,
> I've shown that the genrtc and rtc drivers are doing the same
> thing, so we don't need them both. The remaining three
> architectures (m68k, parisc, powerpc) actually all support
> the newer rtc-generic driver, so we could remove genrtc completely
> if we want to.
> 

Personally, I'd go for the kill and remove genrtc instead of cleaning it
up.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: char: legacy RTC cleanups

[Arnd Bergmann]

On Wednesday 27 April 2016 11:44:10 Alexandre Belloni wrote:
> On 26/04/2016 at 23:44:04 +0200, Arnd Bergmann wrote :
> > I've had these patches in my tree for a while, after the first one
> > had a few issues that are fixed in this new version. The old-style
> > PC RTC driver is now also disabled on m68k (as pointed out by
> > Geert), ppc (it was also blacklisted), and m32r (I showed that
> > it did not build).
> > 
> > For the genrtc driver, rearranging the headers makes it simpler
> > to use and reduces duplication. In case of alpha and mn10300,
> > I've shown that the genrtc and rtc drivers are doing the same
> > thing, so we don't need them both. The remaining three
> > architectures (m68k, parisc, powerpc) actually all support
> > the newer rtc-generic driver, so we could remove genrtc completely
> > if we want to.
> > 
> 
> Personally, I'd go for the kill and remove genrtc instead of cleaning it up.

Right, so we could skip patches 5 and 6, and instead remove the two
headers as we remove the driver. Let's see what the architecture
maintainers think about it, at least powerpc actually enables gen_rtc
in its defconfig, so it might take a while to move it over.

	Arnd

[rtc-linux] Re: char: legacy RTC cleanups

[Arnd Bergmann]

On Wednesday 27 April 2016 11:44:10 Alexandre Belloni wrote:
> On 26/04/2016 at 23:44:04 +0200, Arnd Bergmann wrote :
> > I've had these patches in my tree for a while, after the first one
> > had a few issues that are fixed in this new version. The old-style
> > PC RTC driver is now also disabled on m68k (as pointed out by
> > Geert), ppc (it was also blacklisted), and m32r (I showed that
> > it did not build).
> > 
> > For the genrtc driver, rearranging the headers makes it simpler
> > to use and reduces duplication. In case of alpha and mn10300,
> > I've shown that the genrtc and rtc drivers are doing the same
> > thing, so we don't need them both. The remaining three
> > architectures (m68k, parisc, powerpc) actually all support
> > the newer rtc-generic driver, so we could remove genrtc completely
> > if we want to.
> > 
> 
> Personally, I'd go for the kill and remove genrtc instead of cleaning it up.

Right, so we could skip patches 5 and 6, and instead remove the two
headers as we remove the driver. Let's see what the architecture
maintainers think about it, at least powerpc actually enables gen_rtc
in its defconfig, so it might take a while to move it over.

	Arnd

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: char: legacy RTC cleanups

[Arnd Bergmann]

On Wednesday 27 April 2016 11:44:10 Alexandre Belloni wrote:
> On 26/04/2016 at 23:44:04 +0200, Arnd Bergmann wrote :
> > I've had these patches in my tree for a while, after the first one
> > had a few issues that are fixed in this new version. The old-style
> > PC RTC driver is now also disabled on m68k (as pointed out by
> > Geert), ppc (it was also blacklisted), and m32r (I showed that
> > it did not build).
> > 
> > For the genrtc driver, rearranging the headers makes it simpler
> > to use and reduces duplication. In case of alpha and mn10300,
> > I've shown that the genrtc and rtc drivers are doing the same
> > thing, so we don't need them both. The remaining three
> > architectures (m68k, parisc, powerpc) actually all support
> > the newer rtc-generic driver, so we could remove genrtc completely
> > if we want to.
> > 
> 
> Personally, I'd go for the kill and remove genrtc instead of cleaning it up.

Right, so we could skip patches 5 and 6, and instead remove the two
headers as we remove the driver. Let's see what the architecture
maintainers think about it, at least powerpc actually enables gen_rtc
in its defconfig, so it might take a while to move it over.

	Arnd

Re: char: legacy RTC cleanups

[Geert Uytterhoeven]

Hi Arnd,

On Wed, Apr 27, 2016 at 12:07 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 27 April 2016 11:44:10 Alexandre Belloni wrote:
>> On 26/04/2016 at 23:44:04 +0200, Arnd Bergmann wrote :
>> > I've had these patches in my tree for a while, after the first one
>> > had a few issues that are fixed in this new version. The old-style
>> > PC RTC driver is now also disabled on m68k (as pointed out by
>> > Geert), ppc (it was also blacklisted), and m32r (I showed that
>> > it did not build).
>> >
>> > For the genrtc driver, rearranging the headers makes it simpler
>> > to use and reduces duplication. In case of alpha and mn10300,
>> > I've shown that the genrtc and rtc drivers are doing the same
>> > thing, so we don't need them both. The remaining three
>> > architectures (m68k, parisc, powerpc) actually all support
>> > the newer rtc-generic driver, so we could remove genrtc completely
>> > if we want to.
>> >
>>
>> Personally, I'd go for the kill and remove genrtc instead of cleaning it up.
>
> Right, so we could skip patches 5 and 6, and instead remove the two
> headers as we remove the driver. Let's see what the architecture
> maintainers think about it, at least powerpc actually enables gen_rtc
> in its defconfig, so it might take a while to move it over.

FWIW, all PPC defconfigs (except tqm8xx.dts, which is a more recent platform)
enabling it did that long before my old commit to enable rtc-generic support
on PPC:

commit bcd68a70cb0eee556d86d93133aa150319bd9f53
Author: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Date:   Thu Feb 19 16:50:46 2009 +0100

    powerpc: Hook up rtc-generic, and kill rtc-ppc

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: char: legacy RTC cleanups

[Geert Uytterhoeven]

Hi Arnd,

On Wed, Apr 27, 2016 at 12:07 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 27 April 2016 11:44:10 Alexandre Belloni wrote:
>> On 26/04/2016 at 23:44:04 +0200, Arnd Bergmann wrote :
>> > I've had these patches in my tree for a while, after the first one
>> > had a few issues that are fixed in this new version. The old-style
>> > PC RTC driver is now also disabled on m68k (as pointed out by
>> > Geert), ppc (it was also blacklisted), and m32r (I showed that
>> > it did not build).
>> >
>> > For the genrtc driver, rearranging the headers makes it simpler
>> > to use and reduces duplication. In case of alpha and mn10300,
>> > I've shown that the genrtc and rtc drivers are doing the same
>> > thing, so we don't need them both. The remaining three
>> > architectures (m68k, parisc, powerpc) actually all support
>> > the newer rtc-generic driver, so we could remove genrtc completely
>> > if we want to.
>> >
>>
>> Personally, I'd go for the kill and remove genrtc instead of cleaning it up.
>
> Right, so we could skip patches 5 and 6, and instead remove the two
> headers as we remove the driver. Let's see what the architecture
> maintainers think about it, at least powerpc actually enables gen_rtc
> in its defconfig, so it might take a while to move it over.

FWIW, all PPC defconfigs (except tqm8xx.dts, which is a more recent platform)
enabling it did that long before my old commit to enable rtc-generic support
on PPC:

commit bcd68a70cb0eee556d86d93133aa150319bd9f53
Author: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Date:   Thu Feb 19 16:50:46 2009 +0100

    powerpc: Hook up rtc-generic, and kill rtc-ppc

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[rtc-linux] Re: char: legacy RTC cleanups

[Geert Uytterhoeven]

Hi Arnd,

On Wed, Apr 27, 2016 at 12:07 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 27 April 2016 11:44:10 Alexandre Belloni wrote:
>> On 26/04/2016 at 23:44:04 +0200, Arnd Bergmann wrote :
>> > I've had these patches in my tree for a while, after the first one
>> > had a few issues that are fixed in this new version. The old-style
>> > PC RTC driver is now also disabled on m68k (as pointed out by
>> > Geert), ppc (it was also blacklisted), and m32r (I showed that
>> > it did not build).
>> >
>> > For the genrtc driver, rearranging the headers makes it simpler
>> > to use and reduces duplication. In case of alpha and mn10300,
>> > I've shown that the genrtc and rtc drivers are doing the same
>> > thing, so we don't need them both. The remaining three
>> > architectures (m68k, parisc, powerpc) actually all support
>> > the newer rtc-generic driver, so we could remove genrtc completely
>> > if we want to.
>> >
>>
>> Personally, I'd go for the kill and remove genrtc instead of cleaning it up.
>
> Right, so we could skip patches 5 and 6, and instead remove the two
> headers as we remove the driver. Let's see what the architecture
> maintainers think about it, at least powerpc actually enables gen_rtc
> in its defconfig, so it might take a while to move it over.

FWIW, all PPC defconfigs (except tqm8xx.dts, which is a more recent platform)
enabling it did that long before my old commit to enable rtc-generic support
on PPC:

commit bcd68a70cb0eee556d86d93133aa150319bd9f53
Author: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Date:   Thu Feb 19 16:50:46 2009 +0100

    powerpc: Hook up rtc-generic, and kill rtc-ppc

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: char: legacy RTC cleanups

[Geert Uytterhoeven]

Hi Arnd,

On Wed, Apr 27, 2016 at 12:07 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 27 April 2016 11:44:10 Alexandre Belloni wrote:
>> On 26/04/2016 at 23:44:04 +0200, Arnd Bergmann wrote :
>> > I've had these patches in my tree for a while, after the first one
>> > had a few issues that are fixed in this new version. The old-style
>> > PC RTC driver is now also disabled on m68k (as pointed out by
>> > Geert), ppc (it was also blacklisted), and m32r (I showed that
>> > it did not build).
>> >
>> > For the genrtc driver, rearranging the headers makes it simpler
>> > to use and reduces duplication. In case of alpha and mn10300,
>> > I've shown that the genrtc and rtc drivers are doing the same
>> > thing, so we don't need them both. The remaining three
>> > architectures (m68k, parisc, powerpc) actually all support
>> > the newer rtc-generic driver, so we could remove genrtc completely
>> > if we want to.
>> >
>>
>> Personally, I'd go for the kill and remove genrtc instead of cleaning it up.
>
> Right, so we could skip patches 5 and 6, and instead remove the two
> headers as we remove the driver. Let's see what the architecture
> maintainers think about it, at least powerpc actually enables gen_rtc
> in its defconfig, so it might take a while to move it over.

FWIW, all PPC defconfigs (except tqm8xx.dts, which is a more recent platform)
enabling it did that long before my old commit to enable rtc-generic support
on PPC:

commit bcd68a70cb0eee556d86d93133aa150319bd9f53
Author: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Date:   Thu Feb 19 16:50:46 2009 +0100

    powerpc: Hook up rtc-generic, and kill rtc-ppc

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: char: legacy RTC cleanups

[Geert Uytterhoeven]

Hi Arnd,

On Wed, Apr 27, 2016 at 12:07 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 27 April 2016 11:44:10 Alexandre Belloni wrote:
>> On 26/04/2016 at 23:44:04 +0200, Arnd Bergmann wrote :
>> > I've had these patches in my tree for a while, after the first one
>> > had a few issues that are fixed in this new version. The old-style
>> > PC RTC driver is now also disabled on m68k (as pointed out by
>> > Geert), ppc (it was also blacklisted), and m32r (I showed that
>> > it did not build).
>> >
>> > For the genrtc driver, rearranging the headers makes it simpler
>> > to use and reduces duplication. In case of alpha and mn10300,
>> > I've shown that the genrtc and rtc drivers are doing the same
>> > thing, so we don't need them both. The remaining three
>> > architectures (m68k, parisc, powerpc) actually all support
>> > the newer rtc-generic driver, so we could remove genrtc completely
>> > if we want to.
>> >
>>
>> Personally, I'd go for the kill and remove genrtc instead of cleaning it up.
>
> Right, so we could skip patches 5 and 6, and instead remove the two
> headers as we remove the driver. Let's see what the architecture
> maintainers think about it, at least powerpc actually enables gen_rtc
> in its defconfig, so it might take a while to move it over.

FWIW, all PPC defconfigs (except tqm8xx.dts, which is a more recent platform)
enabling it did that long before my old commit to enable rtc-generic support
on PPC:

commit bcd68a70cb0eee556d86d93133aa150319bd9f53
Author: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Date:   Thu Feb 19 16:50:46 2009 +0100

    powerpc: Hook up rtc-generic, and kill rtc-ppc

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: char: legacy RTC cleanups

[Arnd Bergmann]

On Wednesday 27 April 2016 12:19:59 Geert Uytterhoeven wrote:
> >
> > Right, so we could skip patches 5 and 6, and instead remove the two
> > headers as we remove the driver. Let's see what the architecture
> > maintainers think about it, at least powerpc actually enables gen_rtc
> > in its defconfig, so it might take a while to move it over.
> 
> FWIW, all PPC defconfigs (except tqm8xx.dts, which is a more recent platform)
> enabling it did that long before my old commit to enable rtc-generic support
> on PPC:
> 
> commit bcd68a70cb0eee556d86d93133aa150319bd9f53
> Author: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> Date:   Thu Feb 19 16:50:46 2009 +0100
> 
>     powerpc: Hook up rtc-generic, and kill rtc-ppc

Ah, interesting. I have two observations about that patch:

- you were moving basically in the opposite direction that I am
  trying to bring it now. ;-)

- I see now that four defconfigs (gamecube, powernv, pseries and wii)
  do enable RTC_DRV_GENERIC. For some reason, ppc64_defconfig only
  enables RTC_DRV_DS1307, I assume that is not intentional.

	Arnd

Re: char: legacy RTC cleanups

[Arnd Bergmann]

On Wednesday 27 April 2016 12:19:59 Geert Uytterhoeven wrote:
> >
> > Right, so we could skip patches 5 and 6, and instead remove the two
> > headers as we remove the driver. Let's see what the architecture
> > maintainers think about it, at least powerpc actually enables gen_rtc
> > in its defconfig, so it might take a while to move it over.
> 
> FWIW, all PPC defconfigs (except tqm8xx.dts, which is a more recent platform)
> enabling it did that long before my old commit to enable rtc-generic support
> on PPC:
> 
> commit bcd68a70cb0eee556d86d93133aa150319bd9f53
> Author: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> Date:   Thu Feb 19 16:50:46 2009 +0100
> 
>     powerpc: Hook up rtc-generic, and kill rtc-ppc

Ah, interesting. I have two observations about that patch:

- you were moving basically in the opposite direction that I am
  trying to bring it now. ;-)

- I see now that four defconfigs (gamecube, powernv, pseries and wii)
  do enable RTC_DRV_GENERIC. For some reason, ppc64_defconfig only
  enables RTC_DRV_DS1307, I assume that is not intentional.

	Arnd

Re: char: legacy RTC cleanups

[Arnd Bergmann]

On Wednesday 27 April 2016 12:19:59 Geert Uytterhoeven wrote:
> >
> > Right, so we could skip patches 5 and 6, and instead remove the two
> > headers as we remove the driver. Let's see what the architecture
> > maintainers think about it, at least powerpc actually enables gen_rtc
> > in its defconfig, so it might take a while to move it over.
> 
> FWIW, all PPC defconfigs (except tqm8xx.dts, which is a more recent platform)
> enabling it did that long before my old commit to enable rtc-generic support
> on PPC:
> 
> commit bcd68a70cb0eee556d86d93133aa150319bd9f53
> Author: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> Date:   Thu Feb 19 16:50:46 2009 +0100
> 
>     powerpc: Hook up rtc-generic, and kill rtc-ppc

Ah, interesting. I have two observations about that patch:

- you were moving basically in the opposite direction that I am
  trying to bring it now. ;-)

- I see now that four defconfigs (gamecube, powernv, pseries and wii)
  do enable RTC_DRV_GENERIC. For some reason, ppc64_defconfig only
  enables RTC_DRV_DS1307, I assume that is not intentional.

	Arnd

[rtc-linux] Re: char: legacy RTC cleanups

[Arnd Bergmann]

On Wednesday 27 April 2016 12:19:59 Geert Uytterhoeven wrote:
> >
> > Right, so we could skip patches 5 and 6, and instead remove the two
> > headers as we remove the driver. Let's see what the architecture
> > maintainers think about it, at least powerpc actually enables gen_rtc
> > in its defconfig, so it might take a while to move it over.
> 
> FWIW, all PPC defconfigs (except tqm8xx.dts, which is a more recent platform)
> enabling it did that long before my old commit to enable rtc-generic support
> on PPC:
> 
> commit bcd68a70cb0eee556d86d93133aa150319bd9f53
> Author: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> Date:   Thu Feb 19 16:50:46 2009 +0100
> 
>     powerpc: Hook up rtc-generic, and kill rtc-ppc

Ah, interesting. I have two observations about that patch:

- you were moving basically in the opposite direction that I am
  trying to bring it now. ;-)

- I see now that four defconfigs (gamecube, powernv, pseries and wii)
  do enable RTC_DRV_GENERIC. For some reason, ppc64_defconfig only
  enables RTC_DRV_DS1307, I assume that is not intentional.

	Arnd

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: char: legacy RTC cleanups

[Arnd Bergmann]

On Wednesday 27 April 2016 12:19:59 Geert Uytterhoeven wrote:
> >
> > Right, so we could skip patches 5 and 6, and instead remove the two
> > headers as we remove the driver. Let's see what the architecture
> > maintainers think about it, at least powerpc actually enables gen_rtc
> > in its defconfig, so it might take a while to move it over.
> 
> FWIW, all PPC defconfigs (except tqm8xx.dts, which is a more recent platform)
> enabling it did that long before my old commit to enable rtc-generic support
> on PPC:
> 
> commit bcd68a70cb0eee556d86d93133aa150319bd9f53
> Author: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> Date:   Thu Feb 19 16:50:46 2009 +0100
> 
>     powerpc: Hook up rtc-generic, and kill rtc-ppc

Ah, interesting. I have two observations about that patch:

- you were moving basically in the opposite direction that I am
  trying to bring it now. ;-)

- I see now that four defconfigs (gamecube, powernv, pseries and wii)
  do enable RTC_DRV_GENERIC. For some reason, ppc64_defconfig only
  enables RTC_DRV_DS1307, I assume that is not intentional.

	Arnd

Re: char: legacy RTC cleanups

[Arnd Bergmann]

On Wednesday 27 April 2016 12:19:59 Geert Uytterhoeven wrote:
> >
> > Right, so we could skip patches 5 and 6, and instead remove the two
> > headers as we remove the driver. Let's see what the architecture
> > maintainers think about it, at least powerpc actually enables gen_rtc
> > in its defconfig, so it might take a while to move it over.
> 
> FWIW, all PPC defconfigs (except tqm8xx.dts, which is a more recent platform)
> enabling it did that long before my old commit to enable rtc-generic support
> on PPC:
> 
> commit bcd68a70cb0eee556d86d93133aa150319bd9f53
> Author: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> Date:   Thu Feb 19 16:50:46 2009 +0100
> 
>     powerpc: Hook up rtc-generic, and kill rtc-ppc

Ah, interesting. I have two observations about that patch:

- you were moving basically in the opposite direction that I am
  trying to bring it now. ;-)

- I see now that four defconfigs (gamecube, powernv, pseries and wii)
  do enable RTC_DRV_GENERIC. For some reason, ppc64_defconfig only
  enables RTC_DRV_DS1307, I assume that is not intentional.

	Arnd