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;
MIME-Version: 1.0
References: <20220805205321.19452-1-andriy.shevchenko@linux.intel.com>
 <20220805205321.19452-2-andriy.shevchenko@linux.intel.com> <YvEJefFk7bqW9EpZ@sirena.org.uk>
In-Reply-To: <YvEJefFk7bqW9EpZ@sirena.org.uk>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Mon, 8 Aug 2022 15:43:41 +0200
Message-ID: <CAHp75Vd=RTpnzD4asgx-FQvaQYeO5=aqnR6mT_-xrPY-djs8FA@mail.gmail.com>
Subject: Re: [PATCH v1 2/5] regmap: mmio: Drop unneeded and duplicative checks
 around CLK calls
To:     Mark Brown <broonie@kernel.org>
Cc:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Aidan MacDonald <aidanmacdonald.0x0@gmail.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Aug 8, 2022 at 3:28 PM Mark Brown <broonie@kernel.org> wrote:
> On Fri, Aug 05, 2022 at 11:53:18PM +0300, Andy Shevchenko wrote:
>
> > The commit 6b8e090ecc3d ("regmap: use IS_ERR() to check clk_get()
> > results") assumes that CLK calls return the error pointer when clock
> > is not found. However in the current code the described situation
> > is simply impossible, because the regmap won't be created with
> > missed clock if requested. The only way when it can be the case is
> > what the above mentioned commit introduced by itself, when clock is
> > not provided.
>
> > Taking above into consideration, effectively revert the commit
> > 6b8e090ecc3d and while at it, drop unneeded NULL checks since CLK
> > calls are NULL-aware.
>
> I don't understand the supposed benefit of this.  Yes, the clk API does
> currently accept NULL as a valid clock and returns it as a dummy but
> explicitly taking advantage of that in the way that this does just feels
> more sloppy than the current behaviour.

How? The clock is still checked by NULL by the clock framework. The
above mentioned patch is simply wrong (taking into account modern
behaviour of CCF APIs) and reverting it clears things.

-- 
With Best Regards,
Andy Shevchenko