public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/2]
@ 2017-04-27 13:29 Benjamin Gaignard
  0 siblings, 0 replies; 15+ messages in thread
From: Benjamin Gaignard @ 2017-04-27 13:29 UTC (permalink / raw)
  To: linux-kernel, jic23, linux-iio, knaack.h, lars, pmeerw,
	vilhelm.gray, mwelling
  Cc: fabrice.gasnier, linaro-kernel, benjamin.gaignard,
	Benjamin Gaignard

Those patches aim to complete stm32 timer features support.
The last missing part is to be able to chain to timer blocks
which mean that one of timerX's trigger could be used as clock for timerY.

Since this operating is neither event or buffer triggered mode I would
like to introduce a hardware triggered mode in IIO core.

Benjamin Gaignard (2):
  iio: add hardware triggered operating mode
  iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode

 .../ABI/testing/sysfs-bus-iio-timer-stm32          | 15 ++++++
 drivers/iio/industrialio-core.c                    |  4 +-
 drivers/iio/trigger/stm32-timer-trigger.c          | 61 ++++++++++++++++++++++
 include/linux/iio/iio.h                            |  6 +++
 4 files changed, 84 insertions(+), 2 deletions(-)

-- 
1.9.1

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH 0/2]
@ 2021-10-26 15:27 Antoniu Miclaus
  0 siblings, 0 replies; 15+ messages in thread
From: Antoniu Miclaus @ 2021-10-26 15:27 UTC (permalink / raw)
  To: jic23, robh+dt, linux-iio, devicetree, linux-kernel; +Cc: Antoniu Miclaus

The ADMV1013 is a wideband, microwave upconverter optimized
for point to point microwave radio designs operating in the
24 GHz to 44 GHz radio frequency (RF) range.

Datasheet:
https://www.analog.com/media/en/technical-documentation/data-sheets/ADMV1013.pdf

NOTE:
Currently depends on 64-bit architecture since the input
clock that server as Local Oscillator should support values
in the range 5.4 GHz to 10.25 GHz.

We might need some scaling implementation in the clock
framework so that u64 types are supported when using 32-bit
architectures.

Antoniu Miclaus (2):
  iio: frequency: admv1013: add support for ADMV1013
  dt-bindings: iio: frequency: add admv1013 doc

 .../bindings/iio/frequency/adi,admv1013.yaml  | 110 ++++
 drivers/iio/frequency/Kconfig                 |  13 +
 drivers/iio/frequency/Makefile                |   1 +
 drivers/iio/frequency/admv1013.c              | 579 ++++++++++++++++++
 4 files changed, 703 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml
 create mode 100644 drivers/iio/frequency/admv1013.c

-- 
2.33.1


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH 0/2]
@ 2022-01-07  9:57 Zhenneng Li
  2022-01-07 22:51 ` Rodrigo Siqueira Jordao
  0 siblings, 1 reply; 15+ messages in thread
From: Zhenneng Li @ 2022-01-07  9:57 UTC (permalink / raw)
  To: Alex Deucher
  Cc: Christian König, Xinhui.Pan, David Airlie, Daniel Vetter,
	Rodrigo Siqueira, Leo Li, Harry Wentland, amd-gfx, dri-devel,
	linux-kernel, Zhenneng Li

For adapting radeon rx6600 xt on arm64 platform,
there report some compile errors.

Zhenneng Li (2):
  drm/amdgpu: fix compile error for dcn on arm64
  drm/amdgpu: enable dcn support on arm64

 drivers/gpu/drm/amd/display/Kconfig           |  2 +-
 drivers/gpu/drm/amd/display/dc/calcs/Makefile |  6 +++++
 .../gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 ++++++
 drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  4 +++
 drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 +++
 .../gpu/drm/amd/display/dc/dcn201/Makefile    |  6 +++++
 drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 +++
 drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  6 +++++
 .../gpu/drm/amd/display/dc/dcn302/Makefile    |  6 +++++
 .../gpu/drm/amd/display/dc/dcn303/Makefile    |  6 +++++
 drivers/gpu/drm/amd/display/dc/dcn31/Makefile |  6 +++++
 drivers/gpu/drm/amd/display/dc/dml/Makefile   | 25 +++++++++++++++++++
 drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  7 ++++++
 13 files changed, 88 insertions(+), 1 deletion(-)

-- 
2.25.1


No virus found
		Checked by Hillstone Network AntiVirus

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/2]
  2022-01-07  9:57 Zhenneng Li
@ 2022-01-07 22:51 ` Rodrigo Siqueira Jordao
  0 siblings, 0 replies; 15+ messages in thread
From: Rodrigo Siqueira Jordao @ 2022-01-07 22:51 UTC (permalink / raw)
  To: Zhenneng Li, Alex Deucher, Zhuo, Qingqing, jasdeep.dhillon
  Cc: Christian König, Xinhui.Pan, David Airlie, Daniel Vetter,
	Rodrigo Siqueira, Leo Li, Harry Wentland, amd-gfx, dri-devel,
	linux-kernel, Isabella Basso

Hi Zhenneng,

+ some display folks

First of all, thanks a lot for your patch.

We had a similar patch in the past, but we had to revert it because we 
cannot simply enable DCN for ARM-based systems. You can refer to this 
commit message to get a better context:

https://gitlab.freedesktop.org/agd5f/linux/-/commit/c241ed2f0ea549c18cff62a3708b43846b84dae3

Before enabling ARM, we first need to isolate all FPU code in the DML 
folder fully. You can read more about our strategy at the below link:

https://patchwork.freedesktop.org/series/93042/

And you can see some examples of this effort in the below links:

- https://patchwork.freedesktop.org/series/95504/
- https://patchwork.freedesktop.org/patch/455465/?series=94441&rev=3
- https://patchwork.freedesktop.org/series/98247/

Soon we will submit another series that isolate DCN302, but we still 
need to isolate code from DCN20, DCN10, DCN303, and DCN301.

If you want to help us speed up this process, feel free to look at 
DCN301 or DCN10.

Best Regards
Siqueira

On 2022-01-07 4:57 a.m., Zhenneng Li wrote:
> For adapting radeon rx6600 xt on arm64 platform,
> there report some compile errors.
> 
> Zhenneng Li (2):
>    drm/amdgpu: fix compile error for dcn on arm64
>    drm/amdgpu: enable dcn support on arm64
> 
>   drivers/gpu/drm/amd/display/Kconfig           |  2 +-
>   drivers/gpu/drm/amd/display/dc/calcs/Makefile |  6 +++++
>   .../gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 ++++++
>   drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  4 +++
>   drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 +++
>   .../gpu/drm/amd/display/dc/dcn201/Makefile    |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 +++
>   drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  6 +++++
>   .../gpu/drm/amd/display/dc/dcn302/Makefile    |  6 +++++
>   .../gpu/drm/amd/display/dc/dcn303/Makefile    |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dcn31/Makefile |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dml/Makefile   | 25 +++++++++++++++++++
>   drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  7 ++++++
>   13 files changed, 88 insertions(+), 1 deletion(-)
> 


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH 0/2]
@ 2023-05-23 21:39 Pranav Prasad
  0 siblings, 0 replies; 15+ messages in thread
From: Pranav Prasad @ 2023-05-23 21:39 UTC (permalink / raw)
  To: Jack Wang, James E . J . Bottomley, Martin K . Petersen
  Cc: linux-scsi, linux-kernel, Pranav Prasad

This patch series adds fatal error checks for pm8001 driver
functions pm8001_phy_control() and pm8001_lu_reset().

1. Added a fatal error check in pm8001_phy_control().

2. Added a fatal error check in pm8001_lu_reset().

Changyuan Lyu (1):
  scsi: pm80xx: Add fatal error check for pm8001_phy_control()

Igor Pylypiv (1):
  scsi: pm80xx: Add fatal error check for pm8001_lu_reset()

 drivers/scsi/pm8001/pm8001_sas.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

-- 
2.40.1.698.g37aff9b760-goog


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH 0/2]
@ 2024-10-03  3:23 Finn Thain
  2024-10-03  3:23 ` [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit Finn Thain
  2024-10-03  3:23 ` [PATCH 2/2] m68k: mvme147, mvme16x: Adopt rtc-m48t59 platform driver Finn Thain
  0 siblings, 2 replies; 15+ messages in thread
From: Finn Thain @ 2024-10-03  3:23 UTC (permalink / raw)
  To: Alexandre Belloni, Geert Uytterhoeven
  Cc: Daniel Palmer, Michael Pavone, linux-kernel, linux-m68k,
	linux-rtc

This series removes some duplicate RTC driver code. rtc-m48t59 is tweaked
to bring it into equivalence with the RTC drivers in arch/m68k/mvme*.
Then the latter drivers are removed and platform devices added to make use
of the former.

The second patch depends upon the first, which will require some
coordination between the maintainers of the RTC and m68k subsystems.


Finn Thain (2):
  rtc: m48t59: Accommodate chips that lack a century bit
  m68k: mvme147, mvme16x: Adopt rtc-m48t59 platform driver

 arch/m68k/configs/multi_defconfig   |   1 +
 arch/m68k/configs/mvme147_defconfig |   1 +
 arch/m68k/configs/mvme16x_defconfig |   1 +
 arch/m68k/include/asm/mvme147hw.h   |  19 +---
 arch/m68k/include/asm/mvme16xhw.h   |  18 +--
 arch/m68k/mvme147/config.c          |  54 ++++-----
 arch/m68k/mvme16x/Makefile          |   2 +-
 arch/m68k/mvme16x/config.c          |  56 ++++------
 arch/m68k/mvme16x/rtc.c             | 165 ----------------------------
 drivers/rtc/rtc-m48t59.c            |  31 +++---
 10 files changed, 67 insertions(+), 281 deletions(-)
 delete mode 100644 arch/m68k/mvme16x/rtc.c

-- 
2.39.5


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit
  2024-10-03  3:23 [PATCH 0/2] Finn Thain
@ 2024-10-03  3:23 ` Finn Thain
  2024-10-03  7:46   ` Geert Uytterhoeven
  2024-10-03  8:10   ` Alexandre Belloni
  2024-10-03  3:23 ` [PATCH 2/2] m68k: mvme147, mvme16x: Adopt rtc-m48t59 platform driver Finn Thain
  1 sibling, 2 replies; 15+ messages in thread
From: Finn Thain @ 2024-10-03  3:23 UTC (permalink / raw)
  To: Alexandre Belloni, Geert Uytterhoeven
  Cc: Daniel Palmer, Michael Pavone, linux-m68k, linux-rtc,
	linux-kernel

The m48t59 driver is needed by both SPARC and MVME systems. Linux on
MVME uses 1970 as "year zero" rather than 1968 that's used on SPARC.
Add support for the MVME convention. Otherwise, the RTC on non-SPARC
systems can only read and write dates between 1900 and 1999.

Tested-by: Daniel Palmer <daniel@0x0f.com>
Signed-off-by: Finn Thain <fthain@linux-m68k.org>
---
 drivers/rtc/rtc-m48t59.c | 31 +++++++++++++++----------------
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/rtc/rtc-m48t59.c b/drivers/rtc/rtc-m48t59.c
index f0f6b9b6daec..e2d882ea5c2f 100644
--- a/drivers/rtc/rtc-m48t59.c
+++ b/drivers/rtc/rtc-m48t59.c
@@ -57,6 +57,17 @@ m48t59_mem_readb(struct device *dev, u32 ofs)
 	return readb(m48t59->ioaddr+ofs);
 }
 
+/*
+ * Sun SPARC machines count years since 1968. MVME machines running Linux
+ * count years since 1970.
+ */
+
+#ifdef CONFIG_SPARC
+#define YEAR0 68
+#else
+#define YEAR0 70
+#endif
+
 /*
  * NOTE: M48T59 only uses BCD mode
  */
@@ -82,10 +93,7 @@ static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm)
 		dev_dbg(dev, "Century bit is enabled\n");
 		tm->tm_year += 100;	/* one century */
 	}
-#ifdef CONFIG_SPARC
-	/* Sun SPARC machines count years since 1968 */
-	tm->tm_year += 68;
-#endif
+	tm->tm_year += YEAR0;
 
 	tm->tm_wday	= bcd2bin(val & 0x07);
 	tm->tm_hour	= bcd2bin(M48T59_READ(M48T59_HOUR) & 0x3F);
@@ -108,10 +116,7 @@ static int m48t59_rtc_set_time(struct device *dev, struct rtc_time *tm)
 	u8 val = 0;
 	int year = tm->tm_year;
 
-#ifdef CONFIG_SPARC
-	/* Sun SPARC machines count years since 1968 */
-	year -= 68;
-#endif
+	year -= YEAR0;
 
 	dev_dbg(dev, "RTC set time %04d-%02d-%02d %02d/%02d/%02d\n",
 		year + 1900, tm->tm_mon, tm->tm_mday,
@@ -163,10 +168,7 @@ static int m48t59_rtc_readalarm(struct device *dev, struct rtc_wkalrm *alrm)
 	M48T59_SET_BITS(M48T59_CNTL_READ, M48T59_CNTL);
 
 	tm->tm_year = bcd2bin(M48T59_READ(M48T59_YEAR));
-#ifdef CONFIG_SPARC
-	/* Sun SPARC machines count years since 1968 */
-	tm->tm_year += 68;
-#endif
+	tm->tm_year += YEAR0;
 	/* tm_mon is 0-11 */
 	tm->tm_mon = bcd2bin(M48T59_READ(M48T59_MONTH)) - 1;
 
@@ -199,10 +201,7 @@ static int m48t59_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
 	unsigned long flags;
 	int year = tm->tm_year;
 
-#ifdef CONFIG_SPARC
-	/* Sun SPARC machines count years since 1968 */
-	year -= 68;
-#endif
+	year -= YEAR0;
 
 	/* If no irq, we don't support ALARM */
 	if (m48t59->irq == NO_IRQ)
-- 
2.39.5


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [PATCH 2/2] m68k: mvme147, mvme16x: Adopt rtc-m48t59 platform driver
  2024-10-03  3:23 [PATCH 0/2] Finn Thain
  2024-10-03  3:23 ` [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit Finn Thain
@ 2024-10-03  3:23 ` Finn Thain
  1 sibling, 0 replies; 15+ messages in thread
From: Finn Thain @ 2024-10-03  3:23 UTC (permalink / raw)
  To: Alexandre Belloni, Geert Uytterhoeven
  Cc: Daniel Palmer, Michael Pavone, linux-m68k, linux-rtc,
	linux-kernel

Both mvme147 and mvme16x platforms have their own RTC driver
implementations that duplicate functionality provided by the rtc-m48t59
driver. Adopt the rtc-m48t59 driver and remove the other ones.

Tested-by: Daniel Palmer <daniel@0x0f.com>
Signed-off-by: Finn Thain <fthain@linux-m68k.org>
---
 arch/m68k/configs/multi_defconfig   |   1 +
 arch/m68k/configs/mvme147_defconfig |   1 +
 arch/m68k/configs/mvme16x_defconfig |   1 +
 arch/m68k/include/asm/mvme147hw.h   |  19 +---
 arch/m68k/include/asm/mvme16xhw.h   |  18 +--
 arch/m68k/mvme147/config.c          |  54 ++++-----
 arch/m68k/mvme16x/Makefile          |   2 +-
 arch/m68k/mvme16x/config.c          |  56 ++++------
 arch/m68k/mvme16x/rtc.c             | 165 ----------------------------
 9 files changed, 52 insertions(+), 265 deletions(-)
 delete mode 100644 arch/m68k/mvme16x/rtc.c

diff --git a/arch/m68k/configs/multi_defconfig b/arch/m68k/configs/multi_defconfig
index 638df8442c98..617ac93298f3 100644
--- a/arch/m68k/configs/multi_defconfig
+++ b/arch/m68k/configs/multi_defconfig
@@ -506,6 +506,7 @@ CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_MSM6242=m
 CONFIG_RTC_DRV_RP5C01=m
 CONFIG_RTC_DRV_GENERIC=m
+CONFIG_RTC_DRV_M48T59=m
 # CONFIG_VIRTIO_MENU is not set
 # CONFIG_VHOST_MENU is not set
 # CONFIG_IOMMU_SUPPORT is not set
diff --git a/arch/m68k/configs/mvme147_defconfig b/arch/m68k/configs/mvme147_defconfig
index 2248db426081..4a0928b3b842 100644
--- a/arch/m68k/configs/mvme147_defconfig
+++ b/arch/m68k/configs/mvme147_defconfig
@@ -392,6 +392,7 @@ CONFIG_UHID=m
 CONFIG_RTC_CLASS=y
 # CONFIG_RTC_NVMEM is not set
 CONFIG_RTC_DRV_GENERIC=m
+CONFIG_RTC_DRV_M48T59=y
 # CONFIG_VIRTIO_MENU is not set
 # CONFIG_VHOST_MENU is not set
 # CONFIG_IOMMU_SUPPORT is not set
diff --git a/arch/m68k/configs/mvme16x_defconfig b/arch/m68k/configs/mvme16x_defconfig
index 2975b66521f6..481fb2810f1e 100644
--- a/arch/m68k/configs/mvme16x_defconfig
+++ b/arch/m68k/configs/mvme16x_defconfig
@@ -393,6 +393,7 @@ CONFIG_UHID=m
 CONFIG_RTC_CLASS=y
 # CONFIG_RTC_NVMEM is not set
 CONFIG_RTC_DRV_GENERIC=m
+CONFIG_RTC_DRV_M48T59=y
 # CONFIG_VIRTIO_MENU is not set
 # CONFIG_VHOST_MENU is not set
 # CONFIG_IOMMU_SUPPORT is not set
diff --git a/arch/m68k/include/asm/mvme147hw.h b/arch/m68k/include/asm/mvme147hw.h
index e28eb1c0e0bf..2b147ab1d189 100644
--- a/arch/m68k/include/asm/mvme147hw.h
+++ b/arch/m68k/include/asm/mvme147hw.h
@@ -4,24 +4,7 @@
 
 #include <asm/irq.h>
 
-typedef struct {
-	unsigned char
-		ctrl,
-		bcd_sec,
-		bcd_min,
-		bcd_hr,
-		bcd_dow,
-		bcd_dom,
-		bcd_mth,
-		bcd_year;
-} MK48T02;
-
-#define RTC_WRITE	0x80
-#define RTC_READ	0x40
-#define RTC_STOP	0x20
-
-#define m147_rtc ((MK48T02 * volatile)0xfffe07f8)
-
+#define MVME147_RTC_BASE	0xfffe0000
 
 struct pcc_regs {
    volatile u_long	dma_tadr;
diff --git a/arch/m68k/include/asm/mvme16xhw.h b/arch/m68k/include/asm/mvme16xhw.h
index cc7f5ae1220f..ff1126a51fbe 100644
--- a/arch/m68k/include/asm/mvme16xhw.h
+++ b/arch/m68k/include/asm/mvme16xhw.h
@@ -24,23 +24,7 @@ typedef struct {
 
 #define mvmelp   ((*(volatile MVMElpPtr)(MVME_LPR_BASE)))
 
-typedef struct {
-	unsigned char
-		ctrl,
-		bcd_sec,
-		bcd_min,
-		bcd_hr,
-		bcd_dow,
-		bcd_dom,
-		bcd_mth,
-		bcd_year;
-} MK48T08_t, *MK48T08ptr_t;
-
-#define RTC_WRITE	0x80
-#define RTC_READ	0x40
-#define RTC_STOP	0x20
-
-#define MVME_RTC_BASE	0xfffc1ff8
+#define MVME_RTC_BASE	0xfffc0000
 
 #define MVME_I596_BASE	0xfff46000
 
diff --git a/arch/m68k/mvme147/config.c b/arch/m68k/mvme147/config.c
index 8b5dc07f0811..e2560c6d10b4 100644
--- a/arch/m68k/mvme147/config.c
+++ b/arch/m68k/mvme147/config.c
@@ -19,8 +19,9 @@
 #include <linux/linkage.h>
 #include <linux/init.h>
 #include <linux/major.h>
-#include <linux/rtc.h>
 #include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/rtc/m48t59.h>
 
 #include <asm/bootinfo.h>
 #include <asm/bootinfo-vme.h>
@@ -35,13 +36,9 @@
 
 static void mvme147_get_model(char *model);
 extern void mvme147_sched_init(void);
-extern int mvme147_hwclk (int, struct rtc_time *);
 extern void mvme147_reset (void);
 
 
-static int bcd2int (unsigned char b);
-
-
 int __init mvme147_parse_bootinfo(const struct bi_record *bi)
 {
 	uint16_t tag = be16_to_cpu(bi->tag);
@@ -79,7 +76,6 @@ void __init config_mvme147(void)
 {
 	mach_sched_init		= mvme147_sched_init;
 	mach_init_IRQ		= mvme147_init_IRQ;
-	mach_hwclk		= mvme147_hwclk;
 	mach_reset		= mvme147_reset;
 	mach_get_model		= mvme147_get_model;
 
@@ -88,6 +84,27 @@ void __init config_mvme147(void)
 		vme_brdtype = VME_TYPE_MVME147;
 }
 
+static struct resource m48t59_rsrc[] = {
+	DEFINE_RES_MEM(MVME147_RTC_BASE, 0x800),
+};
+
+static struct m48t59_plat_data m48t59_data = {
+	.type = M48T59RTC_TYPE_M48T02,
+};
+
+static int __init mvme147_platform_init(void)
+{
+	if (!MACH_IS_MVME147)
+		return 0;
+
+	platform_device_register_resndata(NULL, "rtc-m48t59", -1,
+					  m48t59_rsrc, ARRAY_SIZE(m48t59_rsrc),
+					  &m48t59_data, sizeof(m48t59_data));
+	return 0;
+}
+
+arch_initcall(mvme147_platform_init);
+
 static u64 mvme147_read_clk(struct clocksource *cs);
 
 static struct clocksource mvme147_clk = {
@@ -160,28 +177,3 @@ static u64 mvme147_read_clk(struct clocksource *cs)
 
 	return ticks;
 }
-
-static int bcd2int (unsigned char b)
-{
-	return ((b>>4)*10 + (b&15));
-}
-
-int mvme147_hwclk(int op, struct rtc_time *t)
-{
-	if (!op) {
-		m147_rtc->ctrl = RTC_READ;
-		t->tm_year = bcd2int (m147_rtc->bcd_year);
-		t->tm_mon  = bcd2int(m147_rtc->bcd_mth) - 1;
-		t->tm_mday = bcd2int (m147_rtc->bcd_dom);
-		t->tm_hour = bcd2int (m147_rtc->bcd_hr);
-		t->tm_min  = bcd2int (m147_rtc->bcd_min);
-		t->tm_sec  = bcd2int (m147_rtc->bcd_sec);
-		m147_rtc->ctrl = 0;
-		if (t->tm_year < 70)
-			t->tm_year += 100;
-	} else {
-		/* FIXME Setting the time is not yet supported */
-		return -EOPNOTSUPP;
-	}
-	return 0;
-}
diff --git a/arch/m68k/mvme16x/Makefile b/arch/m68k/mvme16x/Makefile
index a8a368c2cbea..02f9e4ad8209 100644
--- a/arch/m68k/mvme16x/Makefile
+++ b/arch/m68k/mvme16x/Makefile
@@ -3,4 +3,4 @@
 # Makefile for Linux arch/m68k/mvme16x source directory
 #
 
-obj-y		:= config.o rtc.o
+obj-y		:= config.o
diff --git a/arch/m68k/mvme16x/config.c b/arch/m68k/mvme16x/config.c
index d1fbd1704d65..cca06f75b873 100644
--- a/arch/m68k/mvme16x/config.c
+++ b/arch/m68k/mvme16x/config.c
@@ -21,9 +21,10 @@
 #include <linux/linkage.h>
 #include <linux/init.h>
 #include <linux/major.h>
-#include <linux/rtc.h>
 #include <linux/interrupt.h>
 #include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/rtc/m48t59.h>
 
 #include <asm/bootinfo.h>
 #include <asm/bootinfo-vme.h>
@@ -39,16 +40,10 @@
 
 extern t_bdid mvme_bdid;
 
-static MK48T08ptr_t volatile rtc = (MK48T08ptr_t)MVME_RTC_BASE;
-
 static void mvme16x_get_model(char *model);
 extern void mvme16x_sched_init(void);
-extern int mvme16x_hwclk (int, struct rtc_time *);
 extern void mvme16x_reset (void);
 
-int bcd2int (unsigned char b);
-
-
 unsigned short mvme16x_config;
 EXPORT_SYMBOL(mvme16x_config);
 
@@ -268,7 +263,6 @@ void __init config_mvme16x(void)
 
     mach_sched_init      = mvme16x_sched_init;
     mach_init_IRQ        = mvme16x_init_IRQ;
-    mach_hwclk           = mvme16x_hwclk;
     mach_reset		 = mvme16x_reset;
     mach_get_model       = mvme16x_get_model;
     mach_get_hardware_list = mvme16x_get_hardware_list;
@@ -312,6 +306,27 @@ void __init config_mvme16x(void)
     }
 }
 
+static struct resource m48t59_rsrc[] = {
+	DEFINE_RES_MEM(MVME_RTC_BASE, 0x2000),
+};
+
+static struct m48t59_plat_data m48t59_data = {
+	.type = M48T59RTC_TYPE_M48T08,
+};
+
+static int __init mvme16x_platform_init(void)
+{
+	if (!MACH_IS_MVME16x)
+		return 0;
+
+	platform_device_register_resndata(NULL, "rtc-m48t59", -1,
+					  m48t59_rsrc, ARRAY_SIZE(m48t59_rsrc),
+					  &m48t59_data, sizeof(m48t59_data));
+	return 0;
+}
+
+arch_initcall(mvme16x_platform_init);
+
 static irqreturn_t mvme16x_abort_int (int irq, void *dev_id)
 {
 	unsigned long *new = (unsigned long *)vectors;
@@ -426,28 +441,3 @@ static u64 mvme16x_read_clk(struct clocksource *cs)
 
 	return ticks;
 }
-
-int bcd2int (unsigned char b)
-{
-	return ((b>>4)*10 + (b&15));
-}
-
-int mvme16x_hwclk(int op, struct rtc_time *t)
-{
-	if (!op) {
-		rtc->ctrl = RTC_READ;
-		t->tm_year = bcd2int (rtc->bcd_year);
-		t->tm_mon  = bcd2int(rtc->bcd_mth) - 1;
-		t->tm_mday = bcd2int (rtc->bcd_dom);
-		t->tm_hour = bcd2int (rtc->bcd_hr);
-		t->tm_min  = bcd2int (rtc->bcd_min);
-		t->tm_sec  = bcd2int (rtc->bcd_sec);
-		rtc->ctrl = 0;
-		if (t->tm_year < 70)
-			t->tm_year += 100;
-	} else {
-		/* FIXME Setting the time is not yet supported */
-		return -EOPNOTSUPP;
-	}
-	return 0;
-}
diff --git a/arch/m68k/mvme16x/rtc.c b/arch/m68k/mvme16x/rtc.c
deleted file mode 100644
index ccbaae1125e6..000000000000
--- a/arch/m68k/mvme16x/rtc.c
+++ /dev/null
@@ -1,165 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- *	Real Time Clock interface for Linux on the MVME16x
- *
- * Based on the PC driver by Paul Gortmaker.
- */
-
-#define RTC_VERSION		"1.00"
-
-#include <linux/types.h>
-#include <linux/errno.h>
-#include <linux/miscdevice.h>
-#include <linux/ioport.h>
-#include <linux/capability.h>
-#include <linux/fcntl.h>
-#include <linux/init.h>
-#include <linux/poll.h>
-#include <linux/rtc.h>	/* For struct rtc_time and ioctls, etc */
-#include <linux/bcd.h>
-#include <asm/mvme16xhw.h>
-
-#include <asm/io.h>
-#include <linux/uaccess.h>
-#include <asm/setup.h>
-
-/*
- *	We sponge a minor off of the misc major. No need slurping
- *	up another valuable major dev number for this. If you add
- *	an ioctl, make sure you don't conflict with SPARC's RTC
- *	ioctls.
- */
-
-static const unsigned char days_in_mo[] =
-{0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
-
-static atomic_t rtc_ready = ATOMIC_INIT(1);
-
-static long rtc_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
-{
-	volatile MK48T08ptr_t rtc = (MK48T08ptr_t)MVME_RTC_BASE;
-	unsigned long flags;
-	struct rtc_time wtime;
-	void __user *argp = (void __user *)arg;
-
-	switch (cmd) {
-	case RTC_RD_TIME:	/* Read the time/date from RTC	*/
-	{
-		local_irq_save(flags);
-		/* Ensure clock and real-time-mode-register are accessible */
-		rtc->ctrl = RTC_READ;
-		memset(&wtime, 0, sizeof(struct rtc_time));
-		wtime.tm_sec =  bcd2bin(rtc->bcd_sec);
-		wtime.tm_min =  bcd2bin(rtc->bcd_min);
-		wtime.tm_hour = bcd2bin(rtc->bcd_hr);
-		wtime.tm_mday =  bcd2bin(rtc->bcd_dom);
-		wtime.tm_mon =  bcd2bin(rtc->bcd_mth)-1;
-		wtime.tm_year = bcd2bin(rtc->bcd_year);
-		if (wtime.tm_year < 70)
-			wtime.tm_year += 100;
-		wtime.tm_wday = bcd2bin(rtc->bcd_dow)-1;
-		rtc->ctrl = 0;
-		local_irq_restore(flags);
-		return copy_to_user(argp, &wtime, sizeof wtime) ?
-								-EFAULT : 0;
-	}
-	case RTC_SET_TIME:	/* Set the RTC */
-	{
-		struct rtc_time rtc_tm;
-		unsigned char mon, day, hrs, min, sec, leap_yr;
-		unsigned int yrs;
-
-		if (!capable(CAP_SYS_ADMIN))
-			return -EACCES;
-
-		if (copy_from_user(&rtc_tm, argp, sizeof(struct rtc_time)))
-			return -EFAULT;
-
-		yrs = rtc_tm.tm_year;
-		if (yrs < 1900)
-			yrs += 1900;
-		mon = rtc_tm.tm_mon + 1;   /* tm_mon starts at zero */
-		day = rtc_tm.tm_mday;
-		hrs = rtc_tm.tm_hour;
-		min = rtc_tm.tm_min;
-		sec = rtc_tm.tm_sec;
-
-		leap_yr = ((!(yrs % 4) && (yrs % 100)) || !(yrs % 400));
-
-		if ((mon > 12) || (day == 0))
-			return -EINVAL;
-
-		if (day > (days_in_mo[mon] + ((mon == 2) && leap_yr)))
-			return -EINVAL;
-
-		if ((hrs >= 24) || (min >= 60) || (sec >= 60))
-			return -EINVAL;
-
-		if (yrs >= 2070)
-			return -EINVAL;
-
-		local_irq_save(flags);
-		rtc->ctrl     = RTC_WRITE;
-
-		rtc->bcd_sec  = bin2bcd(sec);
-		rtc->bcd_min  = bin2bcd(min);
-		rtc->bcd_hr   = bin2bcd(hrs);
-		rtc->bcd_dom  = bin2bcd(day);
-		rtc->bcd_mth  = bin2bcd(mon);
-		rtc->bcd_year = bin2bcd(yrs%100);
-
-		rtc->ctrl     = 0;
-		local_irq_restore(flags);
-		return 0;
-	}
-	default:
-		return -EINVAL;
-	}
-}
-
-/*
- * We enforce only one user at a time here with the open/close.
- */
-static int rtc_open(struct inode *inode, struct file *file)
-{
-	if( !atomic_dec_and_test(&rtc_ready) )
-	{
-		atomic_inc( &rtc_ready );
-		return -EBUSY;
-	}
-	return 0;
-}
-
-static int rtc_release(struct inode *inode, struct file *file)
-{
-	atomic_inc( &rtc_ready );
-	return 0;
-}
-
-/*
- *	The various file operations we support.
- */
-
-static const struct file_operations rtc_fops = {
-	.unlocked_ioctl	= rtc_ioctl,
-	.open		= rtc_open,
-	.release	= rtc_release,
-	.llseek		= noop_llseek,
-};
-
-static struct miscdevice rtc_dev=
-{
-	.minor =	RTC_MINOR,
-	.name =		"rtc",
-	.fops =		&rtc_fops
-};
-
-static int __init rtc_MK48T08_init(void)
-{
-	if (!MACH_IS_MVME16x)
-		return -ENODEV;
-
-	pr_info("MK48T08 Real Time Clock Driver v%s\n", RTC_VERSION);
-	return misc_register(&rtc_dev);
-}
-device_initcall(rtc_MK48T08_init);
-- 
2.39.5


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit
  2024-10-03  3:23 ` [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit Finn Thain
@ 2024-10-03  7:46   ` Geert Uytterhoeven
  2024-10-03 22:20     ` Finn Thain
  2024-10-03  8:10   ` Alexandre Belloni
  1 sibling, 1 reply; 15+ messages in thread
From: Geert Uytterhoeven @ 2024-10-03  7:46 UTC (permalink / raw)
  To: Finn Thain
  Cc: Alexandre Belloni, Daniel Palmer, Michael Pavone, linux-m68k,
	linux-rtc, linux-kernel

Hi Finn,

On Thu, Oct 3, 2024 at 5:27 AM Finn Thain <fthain@linux-m68k.org> wrote:
> The m48t59 driver is needed by both SPARC and MVME systems. Linux on
> MVME uses 1970 as "year zero" rather than 1968 that's used on SPARC.
> Add support for the MVME convention. Otherwise, the RTC on non-SPARC
> systems can only read and write dates between 1900 and 1999.
>
> Tested-by: Daniel Palmer <daniel@0x0f.com>
> Signed-off-by: Finn Thain <fthain@linux-m68k.org>

Thanks for your patch!

> --- a/drivers/rtc/rtc-m48t59.c
> +++ b/drivers/rtc/rtc-m48t59.c
> @@ -57,6 +57,17 @@ m48t59_mem_readb(struct device *dev, u32 ofs)
>         return readb(m48t59->ioaddr+ofs);
>  }
>
> +/*
> + * Sun SPARC machines count years since 1968. MVME machines running Linux
> + * count years since 1970.
> + */
> +
> +#ifdef CONFIG_SPARC
> +#define YEAR0 68
> +#else
 +#define YEAR0 70
> +#endif

This causes a change in behavior on other non-SPARC platforms,
if any out-of-tree platform exists that uses this driver.

So I'd rather use:

    #elif defined(CONFIG_VME)
    #define YEAR0 70
    #else
    #define YEAR0 0
    #endif

> +
>  /*
>   * NOTE: M48T59 only uses BCD mode
>   */
> @@ -82,10 +93,7 @@ static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm)
>                 dev_dbg(dev, "Century bit is enabled\n");
>                 tm->tm_year += 100;     /* one century */
>         }
> -#ifdef CONFIG_SPARC
> -       /* Sun SPARC machines count years since 1968 */
> -       tm->tm_year += 68;
> -#endif
> +       tm->tm_year += YEAR0;

Upon closer look, the driver uses platform data, so a better solution
would be to add the year0 offset to struct m48t59_plat_data.

Another suggestion for improvement, not related to this patch,
would be to differentiate among M48T59, M48T02, and M48T08 by using
platform_driver.id_table and platform_device_id.driver_data, instead
of m48t59_plat_data.type.

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit
  2024-10-03  3:23 ` [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit Finn Thain
  2024-10-03  7:46   ` Geert Uytterhoeven
@ 2024-10-03  8:10   ` Alexandre Belloni
  2024-10-03 22:31     ` Finn Thain
  2024-10-05  4:23     ` Finn Thain
  1 sibling, 2 replies; 15+ messages in thread
From: Alexandre Belloni @ 2024-10-03  8:10 UTC (permalink / raw)
  To: Finn Thain
  Cc: Geert Uytterhoeven, Daniel Palmer, Michael Pavone, linux-m68k,
	linux-rtc, linux-kernel

Hello,

On 03/10/2024 13:23:22+1000, Finn Thain wrote:
> The m48t59 driver is needed by both SPARC and MVME systems. Linux on
> MVME uses 1970 as "year zero" rather than 1968 that's used on SPARC.
> Add support for the MVME convention. Otherwise, the RTC on non-SPARC
> systems can only read and write dates between 1900 and 1999.
> 
> Tested-by: Daniel Palmer <daniel@0x0f.com>
> Signed-off-by: Finn Thain <fthain@linux-m68k.org>
> ---
>  drivers/rtc/rtc-m48t59.c | 31 +++++++++++++++----------------
>  1 file changed, 15 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-m48t59.c b/drivers/rtc/rtc-m48t59.c
> index f0f6b9b6daec..e2d882ea5c2f 100644
> --- a/drivers/rtc/rtc-m48t59.c
> +++ b/drivers/rtc/rtc-m48t59.c
> @@ -57,6 +57,17 @@ m48t59_mem_readb(struct device *dev, u32 ofs)
>  	return readb(m48t59->ioaddr+ofs);
>  }
>  
> +/*
> + * Sun SPARC machines count years since 1968. MVME machines running Linux
> + * count years since 1970.
> + */
> +
> +#ifdef CONFIG_SPARC
> +#define YEAR0 68
> +#else
> +#define YEAR0 70
> +#endif
> +
>  /*
>   * NOTE: M48T59 only uses BCD mode
>   */
> @@ -82,10 +93,7 @@ static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm)
>  		dev_dbg(dev, "Century bit is enabled\n");
>  		tm->tm_year += 100;	/* one century */
>  	}
> -#ifdef CONFIG_SPARC
> -	/* Sun SPARC machines count years since 1968 */
> -	tm->tm_year += 68;
> -#endif
> +	tm->tm_year += YEAR0;
>  

I'm super happy to see someone working on this, while you are it, can
you use m48t59->rtc->start_secs and m48t59->rtc->set_start_time in probe
instead of offsetting tm_year in read_time/set_time so we can later use
device tree or any other mechanism to extend the range?

It is super funny because I was telling Geert that I wanted to get rid
of this #ifdef CONFIG_SPARC two weeks ago at LPC. That could indeed then
come from platform data.

>  	tm->tm_wday	= bcd2bin(val & 0x07);
>  	tm->tm_hour	= bcd2bin(M48T59_READ(M48T59_HOUR) & 0x3F);
> @@ -108,10 +116,7 @@ static int m48t59_rtc_set_time(struct device *dev, struct rtc_time *tm)
>  	u8 val = 0;
>  	int year = tm->tm_year;
>  
> -#ifdef CONFIG_SPARC
> -	/* Sun SPARC machines count years since 1968 */
> -	year -= 68;
> -#endif
> +	year -= YEAR0;
>  
>  	dev_dbg(dev, "RTC set time %04d-%02d-%02d %02d/%02d/%02d\n",
>  		year + 1900, tm->tm_mon, tm->tm_mday,
> @@ -163,10 +168,7 @@ static int m48t59_rtc_readalarm(struct device *dev, struct rtc_wkalrm *alrm)
>  	M48T59_SET_BITS(M48T59_CNTL_READ, M48T59_CNTL);
>  
>  	tm->tm_year = bcd2bin(M48T59_READ(M48T59_YEAR));
> -#ifdef CONFIG_SPARC
> -	/* Sun SPARC machines count years since 1968 */
> -	tm->tm_year += 68;
> -#endif
> +	tm->tm_year += YEAR0;
>  	/* tm_mon is 0-11 */
>  	tm->tm_mon = bcd2bin(M48T59_READ(M48T59_MONTH)) - 1;
>  
> @@ -199,10 +201,7 @@ static int m48t59_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
>  	unsigned long flags;
>  	int year = tm->tm_year;
>  
> -#ifdef CONFIG_SPARC
> -	/* Sun SPARC machines count years since 1968 */
> -	year -= 68;
> -#endif
> +	year -= YEAR0;
>  
>  	/* If no irq, we don't support ALARM */
>  	if (m48t59->irq == NO_IRQ)
> -- 
> 2.39.5
> 

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit
  2024-10-03  7:46   ` Geert Uytterhoeven
@ 2024-10-03 22:20     ` Finn Thain
  0 siblings, 0 replies; 15+ messages in thread
From: Finn Thain @ 2024-10-03 22:20 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Alexandre Belloni, Daniel Palmer, Michael Pavone, linux-m68k,
	linux-rtc, linux-kernel


On Thu, 3 Oct 2024, Geert Uytterhoeven wrote:

> Thanks for your patch!
> 

Thanks for your review.

> > --- a/drivers/rtc/rtc-m48t59.c
> > +++ b/drivers/rtc/rtc-m48t59.c
> > @@ -57,6 +57,17 @@ m48t59_mem_readb(struct device *dev, u32 ofs)
> >         return readb(m48t59->ioaddr+ofs);
> >  }
> >
> > +/*
> > + * Sun SPARC machines count years since 1968. MVME machines running Linux
> > + * count years since 1970.
> > + */
> > +
> > +#ifdef CONFIG_SPARC
> > +#define YEAR0 68
> > +#else
>  +#define YEAR0 70
> > +#endif
> 
> This causes a change in behavior on other non-SPARC platforms,
> if any out-of-tree platform exists that uses this driver.
> 

I'm unaware of any need to support out-of-tree code. Do you see think such 
a requirement would be feasible somehow? Is this documented somewhere?

> So I'd rather use:
> 
>     #elif defined(CONFIG_VME)
>     #define YEAR0 70
>     #else
>     #define YEAR0 0
>     #endif
> 

That is a Y2K bug, right?

> > +
> >  /*
> >   * NOTE: M48T59 only uses BCD mode
> >   */
> > @@ -82,10 +93,7 @@ static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm)
> >                 dev_dbg(dev, "Century bit is enabled\n");
> >                 tm->tm_year += 100;     /* one century */
> >         }
> > -#ifdef CONFIG_SPARC
> > -       /* Sun SPARC machines count years since 1968 */
> > -       tm->tm_year += 68;
> > -#endif
> > +       tm->tm_year += YEAR0;
> 
> Upon closer look, the driver uses platform data, so a better solution 
> would be to add the year0 offset to struct m48t59_plat_data.
> 

I agree.

> Another suggestion for improvement, not related to this patch, would be 
> to differentiate among M48T59, M48T02, and M48T08 by using 
> platform_driver.id_table and platform_device_id.driver_data, instead of 
> m48t59_plat_data.type.
> 

Yes, that's well out-of-scope I think.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit
  2024-10-03  8:10   ` Alexandre Belloni
@ 2024-10-03 22:31     ` Finn Thain
  2024-10-05  4:23     ` Finn Thain
  1 sibling, 0 replies; 15+ messages in thread
From: Finn Thain @ 2024-10-03 22:31 UTC (permalink / raw)
  To: Alexandre Belloni
  Cc: Geert Uytterhoeven, Daniel Palmer, Michael Pavone, linux-m68k,
	linux-rtc, linux-kernel


On Thu, 3 Oct 2024, Alexandre Belloni wrote:

> On 03/10/2024 13:23:22+1000, Finn Thain wrote:
> > The m48t59 driver is needed by both SPARC and MVME systems. Linux on
> > MVME uses 1970 as "year zero" rather than 1968 that's used on SPARC.
> > Add support for the MVME convention. Otherwise, the RTC on non-SPARC
> > systems can only read and write dates between 1900 and 1999.
> > 
> > Tested-by: Daniel Palmer <daniel@0x0f.com>
> > Signed-off-by: Finn Thain <fthain@linux-m68k.org>
> > ---
> >  drivers/rtc/rtc-m48t59.c | 31 +++++++++++++++----------------
> >  1 file changed, 15 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-m48t59.c b/drivers/rtc/rtc-m48t59.c
> > index f0f6b9b6daec..e2d882ea5c2f 100644
> > --- a/drivers/rtc/rtc-m48t59.c
> > +++ b/drivers/rtc/rtc-m48t59.c
> > @@ -57,6 +57,17 @@ m48t59_mem_readb(struct device *dev, u32 ofs)
> >  	return readb(m48t59->ioaddr+ofs);
> >  }
> >  
> > +/*
> > + * Sun SPARC machines count years since 1968. MVME machines running Linux
> > + * count years since 1970.
> > + */
> > +
> > +#ifdef CONFIG_SPARC
> > +#define YEAR0 68
> > +#else
> > +#define YEAR0 70
> > +#endif
> > +
> >  /*
> >   * NOTE: M48T59 only uses BCD mode
> >   */
> > @@ -82,10 +93,7 @@ static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm)
> >  		dev_dbg(dev, "Century bit is enabled\n");
> >  		tm->tm_year += 100;	/* one century */
> >  	}
> > -#ifdef CONFIG_SPARC
> > -	/* Sun SPARC machines count years since 1968 */
> > -	tm->tm_year += 68;
> > -#endif
> > +	tm->tm_year += YEAR0;
> >  
> 
> I'm super happy to see someone working on this, while you are it, can 
> you use m48t59->rtc->start_secs and m48t59->rtc->set_start_time in probe 
> instead of offsetting tm_year in read_time/set_time so we can later use 
> device tree or any other mechanism to extend the range?
> 

Sure, I will look into it.

> It is super funny because I was telling Geert that I wanted to get rid 
> of this #ifdef CONFIG_SPARC two weeks ago at LPC. That could indeed then 
> come from platform data.
> 

I can't test any patches on SPARC, unless there's some way to do so using 
QEMU that would satisfy maintainers. (I rely on Daniel to test my patches 
on an MVME147 system.)

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit
  2024-10-03  8:10   ` Alexandre Belloni
  2024-10-03 22:31     ` Finn Thain
@ 2024-10-05  4:23     ` Finn Thain
  2024-10-20 20:18       ` Alexandre Belloni
  1 sibling, 1 reply; 15+ messages in thread
From: Finn Thain @ 2024-10-05  4:23 UTC (permalink / raw)
  To: Alexandre Belloni
  Cc: Geert Uytterhoeven, Daniel Palmer, Michael Pavone, linux-m68k,
	linux-rtc, linux-kernel


On Thu, 3 Oct 2024, Alexandre Belloni wrote:

> 
> ... while you are it, can you use m48t59->rtc->start_secs and 
> m48t59->rtc->set_start_time in probe instead of offsetting tm_year in 
> read_time/set_time so we can later use device tree or any other 
> mechanism to extend the range?
> 

That didn't work out as I'd hoped. I booted a patched kernel (diff below) 
under qemu-system-sparc64:

~ # for yyyy in 1970 1971 1999 2000 2024 2025 2068 2069 ; do 
date 01010101$yyyy ; hwclock --systohc --utc && hwclock --utc ; echo ; done
Thu Jan  1 01:01:00 UTC 1970
Thu Jan  1 01:01:00 1970  0.000000 seconds

Fri Jan  1 01:01:00 UTC 1971
Tue Nov 24 18:32:44 1998  0.000000 seconds

Fri Jan  1 01:01:00 UTC 1999
Tue Nov 24 18:32:44 2026  0.000000 seconds

Sat Jan  1 01:01:00 UTC 2000
Sun Jan  2 23:29:16 2000  0.000000 seconds

Mon Jan  1 01:01:00 UTC 2024
Tue Jan  2 23:29:16 2024  0.000000 seconds

Wed Jan  1 01:01:00 UTC 2025
Thu Jan  2 23:29:16 2025  0.000000 seconds

Sun Jan  1 01:01:00 UTC 2068
hwclock: RTC_SET_TIME: Numerical result out of range

Tue Jan  1 01:01:00 UTC 2069
hwclock: RTC_SET_TIME: Numerical result out of range

~ # 

Here's the result from an unpatched kernel (v6.11):

~ # for yyyy in 1970 1971 1999 2000 2024 2025 2068 2069 ; do 
date 01010101$yyyy ; hwclock --systohc --utc && hwclock --utc ; echo ; done
Thu Jan  1 01:01:00 UTC 1970
Thu Jan  1 01:01:00 1970  0.000000 seconds

Fri Jan  1 01:01:00 UTC 1971
Fri Jan  1 01:01:00 1971  0.000000 seconds

Fri Jan  1 01:01:00 UTC 1999
Fri Jan  1 01:01:01 1999  0.000000 seconds

Sat Jan  1 01:01:00 UTC 2000
Sat Jan  1 01:01:00 2000  0.000000 seconds

Mon Jan  1 01:01:00 UTC 2024
Mon Jan  1 01:01:00 2024  0.000000 seconds

Wed Jan  1 01:01:00 UTC 2025
Wed Jan  1 01:01:00 2025  0.000000 seconds

Sun Jan  1 01:01:00 UTC 2068
hwclock: RTC_RD_TIME: Invalid argument

Tue Jan  1 01:01:00 UTC 2069
hwclock: RTC_RD_TIME: Invalid argument

~ # 


I'm afraid I don't see how we might avoid adding/subtracting in 
read_time/set_time given that we must avoid messing up the present date 
when users boot into an upgraded kernel.


diff --git a/arch/sparc/kernel/time_32.c b/arch/sparc/kernel/time_32.c
index 08bbdc458596..41ae3d1aa12e 100644
--- a/arch/sparc/kernel/time_32.c
+++ b/arch/sparc/kernel/time_32.c
@@ -255,6 +255,7 @@ static void mostek_write_byte(struct device *dev, u32 ofs, u8 val)
 static struct m48t59_plat_data m48t59_data = {
 	.read_byte = mostek_read_byte,
 	.write_byte = mostek_write_byte,
+	.start_year = 1968,
 };
 
 /* resource is set at runtime */
diff --git a/arch/sparc/kernel/time_64.c b/arch/sparc/kernel/time_64.c
index 60f1c8cc5363..eceb3fadb71a 100644
--- a/arch/sparc/kernel/time_64.c
+++ b/arch/sparc/kernel/time_64.c
@@ -544,6 +544,7 @@ static void mostek_write_byte(struct device *dev, u32 ofs, u8 val)
 static struct m48t59_plat_data m48t59_data = {
 	.read_byte	= mostek_read_byte,
 	.write_byte	= mostek_write_byte,
+	.start_year	= 1968,
 };
 
 static struct platform_device m48t59_rtc = {
diff --git a/drivers/rtc/rtc-m48t59.c b/drivers/rtc/rtc-m48t59.c
index f0f6b9b6daec..d7e1f79cd52b 100644
--- a/drivers/rtc/rtc-m48t59.c
+++ b/drivers/rtc/rtc-m48t59.c
@@ -82,10 +82,6 @@ static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm)
 		dev_dbg(dev, "Century bit is enabled\n");
 		tm->tm_year += 100;	/* one century */
 	}
-#ifdef CONFIG_SPARC
-	/* Sun SPARC machines count years since 1968 */
-	tm->tm_year += 68;
-#endif
 
 	tm->tm_wday	= bcd2bin(val & 0x07);
 	tm->tm_hour	= bcd2bin(M48T59_READ(M48T59_HOUR) & 0x3F);
@@ -108,11 +104,6 @@ static int m48t59_rtc_set_time(struct device *dev, struct rtc_time *tm)
 	u8 val = 0;
 	int year = tm->tm_year;
 
-#ifdef CONFIG_SPARC
-	/* Sun SPARC machines count years since 1968 */
-	year -= 68;
-#endif
-
 	dev_dbg(dev, "RTC set time %04d-%02d-%02d %02d/%02d/%02d\n",
 		year + 1900, tm->tm_mon, tm->tm_mday,
 		tm->tm_hour, tm->tm_min, tm->tm_sec);
@@ -163,10 +154,7 @@ static int m48t59_rtc_readalarm(struct device *dev, struct rtc_wkalrm *alrm)
 	M48T59_SET_BITS(M48T59_CNTL_READ, M48T59_CNTL);
 
 	tm->tm_year = bcd2bin(M48T59_READ(M48T59_YEAR));
-#ifdef CONFIG_SPARC
-	/* Sun SPARC machines count years since 1968 */
-	tm->tm_year += 68;
-#endif
+
 	/* tm_mon is 0-11 */
 	tm->tm_mon = bcd2bin(M48T59_READ(M48T59_MONTH)) - 1;
 
@@ -199,11 +187,6 @@ static int m48t59_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
 	unsigned long flags;
 	int year = tm->tm_year;
 
-#ifdef CONFIG_SPARC
-	/* Sun SPARC machines count years since 1968 */
-	year -= 68;
-#endif
-
 	/* If no irq, we don't support ALARM */
 	if (m48t59->irq == NO_IRQ)
 		return -EIO;
@@ -458,6 +441,10 @@ static int m48t59_rtc_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, m48t59);
 
 	m48t59->rtc->ops = &m48t59_rtc_ops;
+	m48t59->rtc->range_min = mktime64(1900, 1, 1, 0, 0, 0);
+	m48t59->rtc->range_max = mktime64(1999, 12, 31, 23, 59, 59);
+	m48t59->rtc->start_secs = mktime64(pdata->start_year, 1, 1, 0, 0, 0);
+	m48t59->rtc->set_start_time = true;
 
 	nvmem_cfg.size = pdata->offset;
 	ret = devm_rtc_nvmem_register(m48t59->rtc, &nvmem_cfg);
diff --git a/include/linux/rtc/m48t59.h b/include/linux/rtc/m48t59.h
index 9465d5405fe2..b01c514d7079 100644
--- a/include/linux/rtc/m48t59.h
+++ b/include/linux/rtc/m48t59.h
@@ -56,6 +56,9 @@ struct m48t59_plat_data {
 	void __iomem *ioaddr;
 	/* offset to RTC registers, automatically set according to the type */
 	unsigned int offset;
+
+	/* value to be used to initialize rtc->start_secs */
+	time64_t start_year;
 };
 
 #endif /* _LINUX_RTC_M48T59_H_ */

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit
  2024-10-05  4:23     ` Finn Thain
@ 2024-10-20 20:18       ` Alexandre Belloni
  0 siblings, 0 replies; 15+ messages in thread
From: Alexandre Belloni @ 2024-10-20 20:18 UTC (permalink / raw)
  To: Finn Thain
  Cc: Geert Uytterhoeven, Daniel Palmer, Michael Pavone, linux-m68k,
	linux-rtc, linux-kernel

On 05/10/2024 14:23:28+1000, Finn Thain wrote:
> 
> On Thu, 3 Oct 2024, Alexandre Belloni wrote:
> 
> > 
> > ... while you are it, can you use m48t59->rtc->start_secs and 
> > m48t59->rtc->set_start_time in probe instead of offsetting tm_year in 
> > read_time/set_time so we can later use device tree or any other 
> > mechanism to extend the range?
> > 
> 
> That didn't work out as I'd hoped. I booted a patched kernel (diff below) 
> under qemu-system-sparc64:
> 
> ~ # for yyyy in 1970 1971 1999 2000 2024 2025 2068 2069 ; do 
> date 01010101$yyyy ; hwclock --systohc --utc && hwclock --utc ; echo ; done
> Thu Jan  1 01:01:00 UTC 1970
> Thu Jan  1 01:01:00 1970  0.000000 seconds
> 
> Fri Jan  1 01:01:00 UTC 1971
> Tue Nov 24 18:32:44 1998  0.000000 seconds
> 
> Fri Jan  1 01:01:00 UTC 1999
> Tue Nov 24 18:32:44 2026  0.000000 seconds
> 
> Sat Jan  1 01:01:00 UTC 2000
> Sun Jan  2 23:29:16 2000  0.000000 seconds
> 
> Mon Jan  1 01:01:00 UTC 2024
> Tue Jan  2 23:29:16 2024  0.000000 seconds
> 
> Wed Jan  1 01:01:00 UTC 2025
> Thu Jan  2 23:29:16 2025  0.000000 seconds
> 
> Sun Jan  1 01:01:00 UTC 2068
> hwclock: RTC_SET_TIME: Numerical result out of range
> 
> Tue Jan  1 01:01:00 UTC 2069
> hwclock: RTC_SET_TIME: Numerical result out of range
> 
> ~ # 
> 
> Here's the result from an unpatched kernel (v6.11):
> 
> ~ # for yyyy in 1970 1971 1999 2000 2024 2025 2068 2069 ; do 
> date 01010101$yyyy ; hwclock --systohc --utc && hwclock --utc ; echo ; done
> Thu Jan  1 01:01:00 UTC 1970
> Thu Jan  1 01:01:00 1970  0.000000 seconds
> 
> Fri Jan  1 01:01:00 UTC 1971
> Fri Jan  1 01:01:00 1971  0.000000 seconds
> 
> Fri Jan  1 01:01:00 UTC 1999
> Fri Jan  1 01:01:01 1999  0.000000 seconds
> 
> Sat Jan  1 01:01:00 UTC 2000
> Sat Jan  1 01:01:00 2000  0.000000 seconds
> 
> Mon Jan  1 01:01:00 UTC 2024
> Mon Jan  1 01:01:00 2024  0.000000 seconds
> 
> Wed Jan  1 01:01:00 UTC 2025
> Wed Jan  1 01:01:00 2025  0.000000 seconds
> 
> Sun Jan  1 01:01:00 UTC 2068
> hwclock: RTC_RD_TIME: Invalid argument
> 
> Tue Jan  1 01:01:00 UTC 2069
> hwclock: RTC_RD_TIME: Invalid argument
> 
> ~ # 
> 
> 
> I'm afraid I don't see how we might avoid adding/subtracting in 
> read_time/set_time given that we must avoid messing up the present date 
> when users boot into an upgraded kernel.

I'm pretty sure this is avoidable as this is exactly what the offset
mechanism is trying to achieve. I guess the issue is in the RTC core
because both range_min and start_secs are negative which has never been
tested. My plan was to have unit tests for this but this never
happened...


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH 0/2]
@ 2025-05-06  9:08 luyulin
  0 siblings, 0 replies; 15+ messages in thread
From: luyulin @ 2025-05-06  9:08 UTC (permalink / raw)
  To: linus.walleij, robh, krzk+dt, conor+dt, linux-gpio, devicetree,
	linux-kernel, kees, gustavoars, brgl, linux-hardening
  Cc: zhengyu, ningyu, huangyifeng, linmin, fenglin, lianghujun,
	luyulin

  This patch introduces a driver for the Eswin eic7700 SoC pinctrl
  controller, adding support for the pinctrl functionality in the Linux
  kernel. The driver provides basic functionality to manage and control
  the pinctrl signals for the eic7700 SoC.

  The driver integrates with the Linux pinctrl subsystem, enabling kernel
  code to trigger pinctrl operations on hardware and ensuring support for
  pin multiplexing and pin configuration.

  Features:

    Implements support for the Eswin eic7700 SoC pinctrl controller.
    Provides API to manage pinctrl for the eic7700 SoC.
    Integration with the Linux pinctrl subsystem for consistency and
    scalability.

  Supported chips:
    Eswin eic7700 SoC.

  Test:
    I tested this patch on the Sifive HiFive Premier P550 (which uses
    the EIC7700 SoC), including system boot, networking, EMMC, display,
    and other peripherals. The drivers for these modules all use the
    pinctrl module, so this verifies that this pinctrl driver
    patch is working properly.

luyulin (2):
  dt-bindings: pinctrl: eswin: Document for eic7700 SoC
  pinctrl: eswin: Add eic7700 pinctrl driver

 .../pinctrl/eswin,eic7700-pinctrl.yaml        | 156 ++++
 drivers/pinctrl/Kconfig                       |  11 +
 drivers/pinctrl/Makefile                      |   1 +
 drivers/pinctrl/pinctrl-eic7700.c             | 701 ++++++++++++++++++
 4 files changed, 869 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/eswin,eic7700-pinctrl.yaml
 create mode 100644 drivers/pinctrl/pinctrl-eic7700.c

-- 
2.25.1


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2025-05-06  9:09 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-10-03  3:23 [PATCH 0/2] Finn Thain
2024-10-03  3:23 ` [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit Finn Thain
2024-10-03  7:46   ` Geert Uytterhoeven
2024-10-03 22:20     ` Finn Thain
2024-10-03  8:10   ` Alexandre Belloni
2024-10-03 22:31     ` Finn Thain
2024-10-05  4:23     ` Finn Thain
2024-10-20 20:18       ` Alexandre Belloni
2024-10-03  3:23 ` [PATCH 2/2] m68k: mvme147, mvme16x: Adopt rtc-m48t59 platform driver Finn Thain
  -- strict thread matches above, loose matches on Subject: below --
2025-05-06  9:08 [PATCH 0/2] luyulin
2023-05-23 21:39 Pranav Prasad
2022-01-07  9:57 Zhenneng Li
2022-01-07 22:51 ` Rodrigo Siqueira Jordao
2021-10-26 15:27 Antoniu Miclaus
2017-04-27 13:29 Benjamin Gaignard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox