Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Guenter Roeck <groeck7@gmail.com>
Date:   Mon, 31 Oct 2022 15:47:44 -0700
From:   Guenter Roeck <linux@roeck-us.net>
To:     Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc:     Brian Norris <briannorris@chromium.org>,
        Alessandro Zummo <a.zummo@towertech.it>,
        Benson Leung <bleung@chromium.org>, linux-rtc@vger.kernel.org,
        chrome-platform@lists.linux.dev, linux-kernel@vger.kernel.org,
        John Stultz <jstultz@google.com>,
        Stephen Boyd <sboyd@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] rtc: cros-ec: Limit RTC alarm range if needed
Message-ID: <20221031224744.GA2082109@roeck-us.net>
References: <20221029005400.2712577-1-linux@roeck-us.net>
 <Y2ABnbBGSJGM3gSS@mail.local>
 <Y2AMQAf/nDGLNMcI@google.com>
 <Y2BESUyKX4KJzhQZ@mail.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y2BESUyKX4KJzhQZ@mail.local>
Precedence: bulk

On Mon, Oct 31, 2022 at 10:55:21PM +0100, Alexandre Belloni wrote:
> 
> The issue with the current patch is that it forbids going for a better
> solution because you will then take for granted that this driver can't
> ever fail.
> 

This is incorrect. My plan was to get this accepted first and then work
with those responsible on a cleaner solution (which is much more vague).
We can not wait for that cleaner solution now. There is nothing that
prevents us from taking our time to find a cleaner solution, and then
to change the code again to use it.

Guenter