Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 16 Jun 2021 11:14:31 +0200
From:   Maxime Ripard <maxime@cerno.tech>
To:     Andre Przywara <andre.przywara@arm.com>
Cc:     Chen-Yu Tsai <wens@csie.org>,
        Jernej Skrabec <jernej.skrabec@gmail.com>,
        Rob Herring <robh@kernel.org>, Icenowy Zheng <icenowy@aosc.io>,
        Samuel Holland <samuel@sholland.org>,
        linux-arm-kernel@lists.infradead.org, linux-sunxi@googlegroups.com,
        linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org,
        Ondrej Jirman <megous@megous.com>,
        Alessandro Zummo <a.zummo@towertech.it>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        linux-rtc@vger.kernel.org
Subject: Re: [PATCH v7 06/19] rtc: sun6i: Add support for RTCs without
 external LOSCs
Message-ID: <20210616091431.6tm3zdf77p2x3upc@gilmour>
References: <20210615110636.23403-1-andre.przywara@arm.com>
 <20210615110636.23403-7-andre.przywara@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <20210615110636.23403-7-andre.przywara@arm.com>
Precedence: bulk

Hi,

On Tue, Jun 15, 2021 at 12:06:23PM +0100, Andre Przywara wrote:
> Some newer Allwinner RTCs (for instance the one in the H616 SoC) lack
> a pin for an external 32768 Hz oscillator. As a consequence, this LOSC
> can't be selected as the RTC clock source, and we must rely on the
> internal RC oscillator.
> To allow additions of clocks to the RTC node, add a feature bit to ignore
> any provided clocks for now (the current code would think this is the
> external LOSC). Later DTs and code can then for instance add the PLL
> based clock input, and older kernel won't get confused.
>=20
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Honestly, I don't really know if it's worth it at this point.

If we sums this up:

 - The RTC has 2 features that we use, mostly centered around 2
   registers set plus a global one

 - Those 2 features are programmed in a completely different way

 - Even the common part is different, given the discussion around the
   clocks that we have.

What is there to share in that driver aside from the probe, and maybe
the interrupt handling? Instead of complicating this further with more
special case that you were (rightfully) complaining about, shouldn't we
just acknowledge the fact that it's a completely separate design and
should be treated as such, with a completely separate driver?

Maxime